CMake и Visual Studio - указать каталог файлов решений

Question

Я определил файл CMakeLists.txt для моего проекта, который работает правильно.

Я использую CMake GUI для создания проекта Visual Studio, и я прошу создать двоичные файлы (кеш CMAke и другие материалы) в папке Build, которая находится в той же папке, где находится CMakeLists.txt.

Я смог указать, где должны быть созданы исполняемый файл и библиотеки. Есть ли способ указать, где должен быть создан файл решения Visual Studio? Я хотел бы иметь его в корневом каталоге, но в то же время я не хочу иметь также все другие файлы, созданные CMake в каталоге Build.

CMake создает проект I, определенный в CMakeLists.txt, но также и для двух проектов: ALL_BUILD и ZERO_CHECK. В чем их польза? Мне удалось избежать создания ZERO_CHECK с помощью команды set_property(GLOBAL PROPERTY USE_FOLDERS On). Есть ли способ избежать создания ALL_BUILD?

Answer 1

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

я использую CMake GUI для создания Visual Studio Project, и я прошу строить бинарные файлы (кэш CMake и другие вещи) в папке Строить, который в той же папке, где находится CMakeLists.txt.

Нельзя. Всегда делайте out-of-source build с CMake. Я знаю, это странно, когда вы делаете это в первый раз, но поверьте мне: как только вы привыкнете к этому, вы никогда не захотите вернуться.

Единственный факт, что использование источника управления становится намного более удобным, когда файлы кода и сборки должным образом разделены, делают эту функцию убийцей CMake.

Есть ли способ указать, где должен быть создан файл решения Visual Studio?

Вам действительно все равно.

Я понимаю, почему вы чувствуете, что вам нужен полный контроль над тем, как создаются файлы решений и проектов, но вы действительно этого не делаете. Просто укажите цель для решения в качестве источника вашей сборки вне источника и забудьте обо всех других файлах, которые были сгенерированы. Вам не нужно беспокоиться, и вы не хотите волноваться - это именно тот материал, который CMake должен заботиться о для вас.

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

CMake создает проект я определил в CMakeLists.txt, но и два другие проекты: ALL_BUILD и ZERO_CHECK. В чем их польза? Я был , способный избежать создания ZERO_CHECK с помощью команды set_property (GLOBAL PROPERTY USE_FOLDERS On).Есть ли способ для избегать создания ALL_BUILD?

Опять же, вам действительно все равно. CMake определяет пару фиктивных проектов, которые очень полезны для определенного внутреннего вуду, о котором вы не хотите беспокоиться. Сначала они выглядят странно, но вы привыкнете к ним быстрее, чем вы думаете. Просто не пытайтесь выбрасывать их, так как он не будет работать должным образом. Если их взгляд действительно вас так сильно раздражает, рассмотрите moving them to a folder inside the solution, чтобы вам не приходилось постоянно смотреть на них.

Итог: CMake чувствует себя иначе, чем решение VS VS с ручной обработкой несколькими способами. Это немного привыкает, но в конечном итоге это гораздо менее болезненный опыт, чем можно было бы опасаться.

Answer 2

У вас не всегда есть выбор в отношении того, что требует ваша среда. Интеграция GitHub в Visual Studio требует, чтобы файл решения существовал в исходном элементе управления и находится в корне исходного дерева. Это документированное ограничение.

Лучшее, что я смог придумать это добавить этот бит в CMakeList.txt:

# The solution file isn't generated until after this script finishes, 
# which means that: 
# - it might not exist (if this is the first run) 
# - you need to run cmake twice to ensure any new solution was copied 
set(sln_binpath ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.sln) 
if(EXISTS ${sln_binpath}) 
    # Load solution file from bin-dir and change the relative references to 
    # project files so that the in memory copy is as if it had been built in 
    # the source dir. 
    file(RELATIVE_PATH prefix 
     ${CMAKE_CURRENT_SOURCE_DIR} 
     ${CMAKE_CURRENT_BINARY_DIR}) 
    file(READ ${sln_binpath} sln_content) 
    string(REGEX REPLACE 
     "\"([^\"]+).vcxproj\"" 
     "\"${prefix}/\\1.vcxproj\"" 
     sln_content 
     "${sln_content}") 

    # Compare the updated contents with the existing source path sln, if it 
    # exists and is the same we don't want to disturb VS by touching it. 
    set(sln_srcpath ${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.sln) 
    set(old_content "") 
    if(EXISTS ${sln_srcpath}) 
     file(READ ${sln_srcpath} old_content) 
    endif() 
    if(NOT old_content STREQUAL sln_content) 
     file(WRITE ${sln_srcpath} ${sln_content}) 
    endif() 
endif() 

Что было бы полезно, если CMake был способ запуска сценариев пост поколения, но я не мог найти его.

Другие идеи, которые не получилось:

1. обруча CMake внутри сценария, который делает то же самое, но:
   • говоря пользователям запускать отдельный скрипт не проще, чем сказать дважды запустить cmake. Тем более, что нужно дважды запустить cmake - это не внешняя концепция.
2. положить его на этапе предварительной сборки, но
   • здание является общим и изменением сборки редко
   • изменений решения от сборки внутри IDE делает это делать ... вещи
3. использование add_subdirectory, потому что это, предполагают, чтобы закончить первый
   • оказалось в vcxproj сразу сделать, но не го е SLn до позже, но я не пытался так сложно, потому что это добавляет кучу дополнительных помех я не хочу - так что, возможно, это может быть сделано, чтобы работать