2016-02-24 2 views
0

Я пытаюсь построить библиотеку PCRE как часть более крупной сборки. Установки, которые у меня есть, находят на Ubuntu с CMake 3.2.2 с ninja или make, CMake 3.3.2 на окнах с TDM-GCC с использованием Mingw32-make или ниндзя, но не удается при использовании NMake с компилятором visual studio 2015. Сборка выполняется на всех этих платформах, прежде чем добавлять код, описанный ниже.Cmake ExternalProject_Add с библиотекой PCRE не работает с NMake Generator

Я использовал «ExternalProject_Add», чтобы создать цель для этой сборки. Ниже приводится раздел: я установил некоторые переменные и установил внешний проект. Я сократил несколько сообщений для краткости. LibFolder - это папка в исходном дереве с и ProjectBinaryDir вне моей выходной папки.

set(PcreSrcDir "${LibFolder}pcre-8.38/") 
set(PcreLibDir "${ProjectBinaryDir}PCRE-prefix/src/PCRE-build/") 

set(PcreCppLib "${CMAKE_STATIC_LIBRARY_PREFIX}pcrecpp${CMAKE_STATIC_LIBRARY_SUFFIX}") 
#set(PcreLib "${CMAKE_STATIC_LIBRARY_PREFIX}pcre${CMAKE_STATIC_LIBRARY_SUFFIX}") 
#set(PcrePosixLib "${CMAKE_STATIC_LIBRARY_PREFIX}pcre${CMAKE_STATIC_LIBRARY_SUFFIX}") 
set(PcreLibs "${PcreLibDir}${PcreCppLib}") 

set(PcreIncludeDirs "${PcreSrcDir}" "${PcreLibDir}") 

include(ExternalProject) 
ExternalProject_Add(
    PCRE 
    SOURCE_DIR "${PcreSrcDir}" 
    INSTALL_COMMAND "" 
    BUILD_BYPRODUCTS "${PcreLibs}" 
) 

Я использую PcreIncludeDirs позже с include_directories команды, и это, кажется, работает, я не получаю никаких предупреждений или ошибок, связанные с обнаружением заголовков во время любого из сборок.

Я использую PcreLibs и целевое имя PCRE настроить зависимость между библиотекой PCRE и другими библиотеками и исполняемыми файлами в моем встроенных. Вот пример, LibrarySource это и массив исходных файлов для библиотеки в этом примере и ProjectDynamicLib это название So/Dll строится:

add_library(${ProjectDynamicLib} SHARED "${LibrarySource}") 
target_link_libraries(${ProjectDynamicLib} "${PcreLibs}") 
add_dependencies(${ProjectDynamicLib} PCRE) 

Это прекрасно работает с Make и Ninja снова, но терпит неудачу с NMake. Сборки составляют PCRE и большинства моих C++ кода, а затем, когда приходит время, чтобы ссылка на него не может со следующей ошибкой:

NMAKE : fatal error U1073: don't know how to make 'PCRE-prefix\src\PCRE-build\pcrecpp.lib' 
Stop. 
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2' 
Stop. 
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2' 
Stop. 

Сначала я был обеспокоен тем, что имя библиотеки опущен абсолютный путь к моим сборкам каталог. Поэтому я попытался настроить имя несколькими способами, включая реверсирование всех косых черт, чтобы сделать их более дружественными к окну и передать имя библиотеки как относительный путь к target_link_libraries. Я выводю каждую связанную переменную, чтобы я мог вручную проверить их, и я проверил, что библиотеки были созданы, и я нашел их в папке, принадлежащей обозревателю Windows. Я попробовал несколько других глупых вещей, которые не сработали.

Почему это прерывается с использованием NMake и msvc, но работает с использованием Make, Ninja, Mingw32-make при использовании Mingw и GCC?

ответ

0

Я вручную рубил сборку PCRE и обнаружил, что он испускает двоичные файлы с немного разными именами во время разных сборок. Я снова посмотрел в свои выходные каталоги и на мои сборки msvc, я заметил, что в статических библиотеках PCRE был добавлен дополнительный «d» в имени. Таким образом, они были «pcrecppd.lib», «pcred.lib» и «pcreposixd.lib».

Я знаю, что некоторые процессы сборки делают это, чтобы позволить отладочным и выпускным сборкам сосуществовать в одном каталоге компоновки. Поэтому я проверяю, была ли эта сборка отладки, просмотрев в CMOS-кэше .TXT

Рабочая строит - линия 17 до 20 из CMakeCache:

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or 
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. 
CMAKE_BUILD_TYPE:STRING=RELEASE 

В противном случае сборка - строка 17 до 20 из CMakeCache:

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or 
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. 
CMAKE_BUILD_TYPE:STRING=DEBUG 

В предположении, что это моя проблема, я решил установите внешний проект только для создания в режиме деблокирования. Мы можем настроить его на отладку вручную в маловероятном случае, когда нам нужно отлаживать библиотеку регулярных выражений. Я использовал CMAKE_ARGS, как описано на странице ExternalProject cmake documentation.

include(ExternalProject) 
ExternalProject_Add(
    PCRE 
    SOURCE_DIR "${PcreSrcDir}" 
    INSTALL_COMMAND "" 
    BUILD_BYPRODUCTS "${PcreLibs}" 
    *CMAKE_ARGS "-DCMAKE_BUILD_TYPE:STRING=Release"* 
) 

Я удалил всю свою папку сборки (чтобы обеспечить чистое состояние и избежать загрязнений с моим ручным лужением) и перенастроить с CMake и восстановил программное обеспечение. На этот раз он построен и связан без ошибок.

Я до сих пор не знаю, почему vs и nmake решили построить отладку, а другие инструментальные цепочки по умолчанию были выпущены, я также не знаю, какая из «D» была ошибкой PCRE, vs или nmake или CMake.

+0

Я не буду отмечать свой ответ в качестве ответа в течение как минимум 24 часов, потому что сообщество часто придумывает что-то лучшее, чем я, и я предпочел бы выбрать ответ, который объясняет, почему, а не только то, что произошло. – Sqeaky

Смежные вопросы