2015-02-02 12 views
5

Я пытаюсь перейти от Visual Studio к Jetbrains (awesome) CLion IDE, который использует CMake для организации проектов.CMake эквивалентен листам свойств Visual Studio (.vsprops)

До сих пор переход был плавным: создание проектов CMake и их импорт в CLion легко, и я могу начать кодирование на одной пластине, а затем продолжить работу над другой без проблем.

Однако один из аспектов Visual Studio, что я не мог найти эквивалент в CMake является property sheets: Я использую их в основном для проведения трактов каталогов включения и связывающие библиотеки для библиотек (т.е. один .vsprops файла для каждой библиотеки , например OpenCV.vsprops, Boost.vsprops и т. д.).

Таким образом, в VS я мог бы совместно использовать файл библиотеки .vsprops между различными проектами без необходимости настраивать пути/библиотеки каждый раз.

Имеет ли CMake аналогичный механизм для листов свойств Visual Studio? Как можно хранить библиотеки include/libs в файле CMake-parsable, затем «импортировать» его в CMakeLists.txt, чтобы связать его с библиотекой?

В общем, что я хочу сделать, это:

  1. Создание «лист свойств Cmake» (из-за отсутствия лучшего названия) для данной библиотеки.
  2. Затем, в CMakeLists.txt, напишите что-нибудь вроде link_target_to_libs(myTarget "path/to/propertySheet1" "path/to/propertySheet2" ...).
+0

*** Как я могу имитировать таблицы свойств Visual Studio (для библиотек) в CMake *** Вы должны генерировать эти самостоятельно с помощью CMake команды для создания файлов. – drescherjm

+0

*** Я использую их в основном для хранения путей каталогов include и связывания библиотек для библиотек *** Я бы просто использовал обработку CMake, если библиотеки и файлы include. Или вы не хотите создавать проекты Visual Studio с помощью CMake. – drescherjm

+0

Я отредактировал последнюю часть своего сообщения, чтобы прояснить мои намерения :) И вы правы, я больше не хочу использовать VS. Я просто хочу иметь проекты CMake, исходный код которых я буду редактировать с помощью CLion. – 865719

ответ

1

Поскольку я действительно хочу включить включение/соединение библиотек в однострочную команду, и, насколько мне известно (базовое) знание CMake, я считаю, что нужно сделать некоторый компромисс - главным образом, разделяя цель имя переменная между CMakeLists.txt и «листы свойств». Так это мое решение ...пока кто-то предлагает простой/очиститель одно:

  1. CMake свойство листа является .cmake текстовый файл,
  2. хорошо известно имя переменной - TARGET - обозначает цель (т.е. первый аргумент add_executable()),
  3. Помимо команд библиотеки-конкретно, .cmake файл содержит вызов target_include_directories(${TARGET} PRIVATE ${PATH_TO_INCLUDE_DIR}) и target_link_libraries(${TARGET} ${LIST_OF_LIBS}),
  4. для того, чтобы использовать/ссылку против библиотеки, вызовите include("path/to/.cmake") в CMakeLists.txt.

Я успешно построен и выполнил простую программу, которая использует X11 и OpenCV со следующими файлами:

x11.cmake

target_include_directories(${TARGET} PRIVATE "/usr/include/X11") 
target_link_libraries(${TARGET} "/usr/lib/x86_64-linux-gnu/libX11.so") 

opencv.cmake

# OpenCV-specific stuff 
set(OpenCV_DIR "/PATH/TO/OPENCV/INSTALL/DIR/share/OpenCV") # path to OpenCVConfig.cmake 
find_package(OpenCV REQUIRED) 
# include path 
target_include_directories(${TARGET} PRIVATE ${OpenCV_INCLUDE_DIRS}) 
# linking libs 
target_link_libraries(${TARGET} opencv_world opencv_ts) 

CMakeLists.txt

cmake_minimum_required(VERSION 2.8.4) 
project(hello_clion) 

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") 

## hello-clion ############################## 
# make a new target name 
set(TARGET hello-clion) 

# find sources 
file(GLOB_RECURSE SOURCE_FILES "src/*.cpp" "src/*.hpp") 

# declare a target 
add_executable(${TARGET} ${SOURCE_FILES}) 

# link the libraries (to the last-declared ${TARGET}, which should be the last-added executable) 
include("x11.cmake") 
include("opencv.cmake") 
############################################# 

main.cpp

#include <cstdio> 
#include <cstdlib> 
#include <cstring> 
#include <thread> 

#include <opencv2/opencv.hpp> 

#include <Xlib.h> 

int main_x11() 
{ 
    // adapted from: http://rosettacode.org/wiki/Window_creation/X11#Xlib 
} 

int main_ocv() 
{ 
    // adapted from: http://docs.opencv.org/doc/tutorials/introduction/display_image/display_image.html#source-code 
} 

int main() 
{ 
    using namespace std; 

    thread tocv(main_ocv); 
    thread tx11(main_x11); 

    tocv.join(); 
    tx11.join(); 

    return 0; 
} 

Теперь, каждый раз, когда я хочу использовать OpenCV в проекте/программе, я просто поставить include("opencv.cmake") в соответствующем CMakeLists.txt.

+0

Это не будет хорошим решением при определении нескольких целей в одном каталоге. Я предлагаю вам посмотреть ссылки на документы, которые я предоставил. – steveire

+0

Можете ли вы рассказать о том, почему это решение может быть проблематичным, пожалуйста? Я вижу, что путь * include * может быть загрязнен * (т. Е. Содержать ненужные каталоги), но это, я думаю, не проблема ... не так ли? – 865719

+0

Я отредактировал свое решение, чтобы использовать 'target_include_directories()' для того, чтобы каталоги были включены для каждой цели. – 865719

1

В CMake библиотеки могут экспортировать пакет с импортными целями, которые другое buildsystems импортировать с помощью find_package:

http://www.cmake.org/cmake/help/v3.1/manual/cmake-packages.7.html

http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html

http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#imported-targets

Вместо «ссылки на недвижимость листы ', вы ссылаетесь на цели IMPORTED.

target_link_libraries(myTarget Dep1::Dep1 Dep2::Dep2) 

Не все библиотеки создают ИМПОРТНЫЕ цели, и не все предоставляют пакеты конфигурационных файлов cmake. В этих случаях (в том числе OpenCV и бустер), CMake предоставляет найти модули:

http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#find-modules

, который вы используете с find_package и ссылки на содержимое переменных.

1

Это, кажется, отлично работает, но, безусловно, могут быть проблемы, которые я не обнаружил. (Я был обеспокоен несколькими макросами, добавив те же самые целевые_link_libraries, что и «уже определенные» ошибки связывания, но по крайней мере g ++ 5.1.0 обрабатывает одно и то же имя библиотеки несколько раз без ошибок.)

В корне CMakeLists.txt, ПЕРЕД add_subdirectory() вызывает или шарики, включают в себя:

macro(USES_WX) 
    include_directories(SYSTEM /usr/local/include/wx-3.0) 
    include_directories(SYSTEM /usr/local/lib/wx/include/gtk3-unicode-3.0) 
    link_directories(/usr/local/lib) 
    add_definitions(-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread) 
    target_link_libraries(${TARGET} pthread wx_gtk3u_xrc-3.0 wx_gtk3u_html-3.0 wx_gtk3u_qa-3.0 wx_gtk3u_adv-3.0 wx_gtk3u_core-3.0 wx_baseu_xml-3.0 wx_baseu_net-3.0 wx_baseu-3.0) 
endmacro() 

(Вы можете сделать макрос больше фантазии, как проверка, если CMAKE_BUILD_TYPE является «Debug» или «Release» связать с соответствующими библиотеками, меняются определения препроцессора и т. д. См. http://www.cmake.org/cmake/help/v3.0/command/if.html)

И есть CMakeLists.txt вашего проекта будет так:

set(TARGET myProgramName) 
add_executable(${TARGET} myProgramName.cpp) 
USES_WX() 

^^ The макровызове MUST быть после add_executable()


И, если вы хотите несколько целевой поддержки, модифицировать line в корневой секции CMakeLists.txt, показанной выше:

... 
    target_link_libraries(${ARGV0} pthread wx_gtk3u_xrc-3.0 ...) 
    ... 

И у вас есть CMakeLists вашего проекта.TXT быть, как это (меньше строк, но больше шансов на ошибку):

add_executable(myProgramName myProgramName.cpp) 
USES_WX(myProgramName) 
+0

Благодарим вас за ответ. Я должен сказать, что я улучшил свое решение, «инкапсулируя» содержимое листов свойств .cmake' внутри функций, которые принимают для ввода имени цели (мне больше не нужно полагаться на глобальную переменную «TARGET»). Кроме того, я создал функцию 'add_executable()' -like, которая заботится об управлении включением свойств листов и т. Д. На самом деле имеет некоторое сходство с тем, что вы предложили :) – 865719

+0

Если у меня будет время, я поставлю свой окончательное решение в моем публичном репо или где-то ... может оказаться полезным для людей, у которых, как и я, есть локальное репо libs и нужен быстрый 1-строчный механизм для их использования в своих проектах на основе cmake ... – 865719

+0

было бы здорово, если бы вы могли его где-то поставить. Я был бы рад увидеть лучшее/другое решение. – user1902689