compile options and static import path

[jacobblock]

Hi, very interesting idea and I wanted to get your feedback on a couple ideas.

The first is an issue with an independent generate + build process. I am getting the following error:

gtest.lib(gtest-all.cc.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in mytest.cpp.obj

My thoughts (not an expert in this area) are the separate execute_process is not pulling in my current CMake options, such as MSVC compile flags. Do you see a convenient way of forwarding these in the DownloadProject.cmake?

2. I don't want these sources in the same folder as my tests. I've roughly injected a static path for this:

include(CMakeParseArguments)

set(DOWNLOAD_PROJECT_DIR ${CMAKE_CURRENT_LIST_DIR})

function(download_project)
...
    configure_file("${DOWNLOAD_PROJECT_DIR}/DownloadProject.CMakeLists.cmake.in" ${DL_ARGS_PROJ}-download/CMakeLists.txt)
...
endfunction()

Curious about your thoughts. Thanks!

[craigscott-crascit]

Regarding (1), DownloadProject does not build anything, it only downloads. The building part would be your own project pulling it in via add_subdirectory(), which would be something outside of what DownloadProject does. I suggest you ask a question on somewhere like Stackoverflow with code samples and something people can use to reproduce your problem.

For (2), if you were using an out-of-source build, then the downloaded project would be put in your BUILD area, not your SOURCE area. When it is unpacked, again it will be in the BUILD area. This would already seem to satisfy what you want with the downloaded project being separated from your tests (assuming you meant your test sources). If you are doing an in-source build, then I strongly recommend you explore doing out-of-source builds instead.

[jacobblock]

Thank you for the comments. I'll keep investigating (1).

Regarding (2), I am doing out of source builds. Maybe to better clarify, the issue is trying to use DownloadProject as a subtree or submodule. Keeping DownloadProject in its own directory makes the function call for download_project fail to find the configuration file DownloadProject.CMakeLists.cmake.in

My setup looks like:

+ CMakeLists.txt
+ thirdparty/
  + CMakeLists.txt (imports DownloadProject's cmake and adds googletest subfolder)
  + DownloadProject/ (this git project)
  + googletest/
    + CMakeLists.txt (calling download_project and sets up helper functions)

Calling include("DownloadProject/DownloadProject.cmake") is fine, but then trying to call download_project from somewhere else will fail, such as when trying to be used inside googletest/CMakeLists.txt.

[craigscott-crascit]

Thanks, that made your problem clearer. I've now fixed the issue so you shouldn't need your workaround for (2) any more.

[jacobblock]

In case it helps others: My issues with (1) was pulling release-1.7.0 instead of masters at the time (new directory structure and improved CMake handling), and more importantly set(gtest_force_shared_crt yes).

Your (2) works well for me also. Thanks!