Re: [CMake] GTest confusion - linking to project being tested
Split your monolithic executable into a library and its main: add_library(core core.cpp) add_executable(main main.cpp) target_link_libraries(main core) Then, you can create gtest file and link to the core lib: add_executable(test_core test_core.cpp) target_link_libraries(test_core gtest gtest_main core) add_test(NAME test_core COMMAND test_core) IMHO other tricks will make your build system hackish and error prone. You'd better keep the code and the tests in sync. The standard way is to just put the tests beside the code that it is testing. Francis Le mer. 24 avr. 2019 à 17:38, cen a écrit : > Hi > > I am essentially trying to solve this problem: > > https://stackoverflow.com/questions/19886397/how-to-solve-the-error-lnk2019-unresolved-external-symbol-function/30667584#30667584 > > and I have hit a wall. > > Using CMake to generate solution with two VC projects, one is a > monolithic .exe the other is a gtest project meant to test a few > functions from the exe. > > I am having a problem linking to main project in gtest project because: > > 1. The project being tested is an exe, not a lib. > > 2. Ideally I don't want to have all h/cpp files pulled up in the gtest > project, only have the actual test files in there. > > 3. Adding the main project as a reference to gtest project didn't help > (suggestion from SO thread). > > 4. Manually adding main project .obj files in gtest as linker input > solves the problem and is essentially the solution I would like to > achieve with CMake. > > 5. I hit another unpleasant snafu after #4 because main and gtest > project implement a main() method and this fails to build. But I guess > this can be avoided by renaming > > the gtest main and changing the entry point of the gtest project. > > > So if 5 is solvable, what I really need is a CMake solution to #4.. to > automatically build the tested project and link to it's object files in > gtest project. > > > This seems to me to be a really obvious case for testing so I am not > sure whether it really is that complicated or I am doing things wrong. > > > Bets regards, cen > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Fake dependencies of executables to static libs
Maybe the problem is related to Cotire? I see that it is used in mredis. I tried to reproduce the issue, and it behaves correctly. You might want to try to reproduce using the following minimal repo: https://gitlab.com/fgiraldeau/cotire-demo Francis Le jeu. 4 avr. 2019 à 03:17, Stephan Menzel a écrit : > > Hello Paul and Shoaib, > > I'm answering to the both of you. > > On Thu, Apr 4, 2019 at 7:13 AM Paul Smith wrote: >> >> Now although I don't understand the exact reasons behind that, over the >> years came to accept that depedencies between the lib and the resulting >> artifcats are not working. Like, when I change a source file to mylib, the >> lib will get rebuilt but the resulting test tool won't be relinked. >> >> >> This is definitely not true, as stated. I feel like I must be missing >> something about your stated environment because this is really basic, >> fundamental CMake behavior, which has always worked. > > > First of all, thanks for the information. I was not aware that this is > supposed to work. As I said, I've been struggling with this issue for years > now and I recall posting this to this list too but the only explanation I > ever found was something along the lines of "dependencies would exist to > objects inside the lib, not the lib as it is a static archive". But I'm > pulling this out of my 'memory' now, nothing to rely on. All I remembered is > that this is not supposed to work. But now you say the opposite, which gives > me a little hope. > >> >> If in your environment you are not seeing executables rebuilt when libraries >> they depend on are updated, then there is something more complex about it >> than the straightforward case you provide above. > > > I have seen this in two major projects I have been working on in the last > years. Both were Linux and Windows, MSVC 14 and 15 on Windows. And I do > believe the issue is on Windows. I am not sure which CMake version I have > seen this first on. Let's make it 3.10.x cause this was when I posted this to > the list last time but by then I was already having the problem for a longer > time. > > Today I am using CMake version 3.13.2 but I have been using many different > versions up to this one. > > Both projects were large but not huge, having about 10 - 15 targets plus > additional 50 unit tests plus another 5 test tools. Unfortunately I cannot > publish the projects themselves but one that I currently see the issue with > is mredis (https://github.com/MrMoose/mredis) which, among others, is pulled > in as a submodule. C++ only, some protobuf code generation is involved but > not in the targets that I'm talking about. > > Since the issue has been persisting for so long now, the projects and > CMakeLists have substantially changed many times, so it's really hard to come > up with something I would consider 'strange' or 'different' as a possible > explanation. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] Mixted C++/Fortran library on Windows [resolved]
I just wanted to share a solution for mixing C++ and Fortran programs on Windows using Visual Studio and Intel Fortran. The build was failing at link time with undefined symbols comming from fortran code. Actually, none of the fortran sources were compiled, even though it was working fine on Linux using Makefiles. When generating a shared library with both fortran and c++ sources like this: add_library(mix foo.f bar.cpp) It produces the following .vcxproj (snippet): The None compiler, well, does nothing. The trick is to create two libraries, one for C++ code and the other for the fortran code: add_library(foo foo.f) add_library(bar bar.cpp) Then, both .vcxproj and .vfproj gets created and the fortran code is compiled. It might be useful to document it somewhere. Perhaps it is already documented and I haven't found it? Cheers, Francis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] fixup-bundle usability
You are right, the fixup bundle is difficult to use. Here are some
undocumented tips:
Put the install(CODE) with the fixup_bundle() call in a CMakeLists.txt in
its own directory. In your main CMakeLists.txt file, add this directory
with add_subdirectory() last. This install(CODE) will run after all the
other install directive, otherwise the fixup_bundle() might run before
other targets are installed.
The main thing is to build the library path variable. Yes, this information
can be recovered from the target itself, but fixup_bundle() won't gather
that info for you. Here is an example with Qt:
get_target_property(QT_CORE_LIB Qt5::Core LOCATION)
get_filename_component(QT_RUNTIME_DIR "${QT_CORE_LIB}" DIRECTORY)
list(APPEND LIBS_PATH "${QT_RUNTIME_DIR}")
If you are using VTK, there is already a variable:
list(APPEND LIBS_PATH "${VTK_RUNTIME_LIBRARY_DIRS}")
You might as well run windeployqt (and similar tool for other platforms)
inside install(CODE) script if you have a Qt app, such that the styles and
the plugins and other stuff gets copied.
execute_process(COMMAND windeployqt.exe --release \"\${MAIN_APP}\")
Workaround wrong tool detection using MinGW on Windows:
if(WIN32 AND NOT MSVC)
set(GP_TOOL "objdump")
endif()
install(CODE "\
...
include(BundleUtilities)
set(gp_tool \"${GP_TOOL}\")
fixup_bundle(\"\${MAIN_APP}\" \"\" \"${LIBS_PATH}\")
...
And there is the escaping... You have to escape quotes inside
the script. Escape the '$' sign if you want to refer to the
variable at install time. Remember that you don't have access
to configure-time variables at install time. Unescaped '$' prefix
will be replaced by its value at configure time, somewhat like
a macro or a template.
To see the generated script, look into ${CMAKE_BINARY_DIR} with
the directory name corresponding to the CMakeLists.txt containing
the install(CODE). Example:
${CMAKE_SOURCE_DIR}/cmake/bundle/CMakeLists.txt
-> ${CMAKE_BINARY_DIR}/cmake/bundle/cmake_install.cmake
You can check the generated script, its very
handy when things go wrong.
Also, it is easier to put all libraries and binaries in their
own directory. I have this near the begining of my project's
CMakeLists.
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
If you have some library that you don't want in your bundle,
you might want to disable install for it, for instance,
google test:
add_subdirectory(3rdparty/googletest/ EXCLUDE_FROM_ALL)
I'm using "ntldd.exe -R" on Windows to check the dependencies manually
(its very much like ldd on Linux). It is much more handy than
dependency walker.
Fixup_bundle is not magical either. The library dependencies must be
known beforehand. It means that if you do some dlopen() tricks at
runtime, fixup_bundle() cannot know that and you will have to install
these libraries manually yourself. One notable example of this is
Intel MKL using the Single Dynamic Library (mkl_rt). Using this
library entry point simplifies the linking and will load the
best library at runtime depending on the hardware. Fixup_bundle() will
copy only mkl_rt and you have to copy the other mkl libraries to
avoid runtime error.
Fixup bundle is tricky to put in place, but having a fixed list
of libraries to copy is even more cumbersome and flaky. When
supplied with the proper directories, the bundle is right every time.
Francis
Le sam. 16 févr. 2019 à 04:04, Andreas Naumann a
écrit :
> Dear CMakers,
>
> recently I tried to bundle an application in Windows. From the
> documentation [1] I see that I should provide the directories to the
> non-system libraries.
>
> But these information should be already in the properties of the
> targets, arent they? Is there any extension in cmake, that provides
> these paths?
>
> How do other users handle dependencies to external dlls?
>
>
> [1] https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html
>
> Regards,
> Andreas
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
--
Francis Giraldeau
--
Powered by www.kitware.com
[CMake] Qt translation handling
Here is a small snipped I wanted to share about generation of qt translation
files.
The Qt translations are managed using two files: ts and qm. The ts files are
edited by translators and updated from source files. Therefore, they must be
added to the repository. To include the translations in the application, qm
binary file is generated. This file is generated in the build tree and must
not be added to the repository.
Qt5 suggests to use qt5_create_translation() macro. However, this macro
regenerate the ts file at build time. It is very inconvenient when working
on multiple branches, because it forces to either commit the modified
translation file or discard the update. Instead, we use a custom target
"make translations" that update ts files only when requested explicitely.
set(TS_FILES
${CMAKE_CURRENT_SOURCE_DIR}/translations/app_fr.ts
)
file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui")
add_custom_target(translations)
foreach(_ts_file ${TS_FILES})
# generate a sensible name for this translation file
get_filename_component(_ts_name ${_ts_file} NAME_WE)
# call lupdate ourselves
add_custom_command(
OUTPUT "${_ts_file}"
DEPENDS ${TS_SOURCES}
COMMAND ${Qt5_LUPDATE_EXECUTABLE} -recursive
${CMAKE_CURRENT_SOURCE_DIR} -ts ${_ts_file}
)
# create a target that depends on the generated files
add_custom_target(translate_${_ts_name} DEPENDS ${_ts_file})
# attach the custom target for this ts file to the parent target
add_dependencies(translations translate_${_ts_name})
endforeach()
# generate qm files
qt5_add_translation(QM_FILES ${TS_FILES})
configure_file(translations.qrc ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
add_executable(App
${QM_FILES}
${CMAKE_CURRENT_BINARY_DIR}/translations.qrc
)
Cheers,
Francis
--
Francis Giraldeau
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How do I use install() with targets that might not be built?
To customize the build and install, I would suggest to use an
install(TRAGET) wrapper for each target. It allows to define an option for
each of them.
* The list of targets must be recorded in a global property.
* The install option is constructed using the target name
* call generate_install_config() after all targets to get a template that
you can customize and use as cmake initial cache
You might be able to adapt this to your needs.
Cheers,
set_property(GLOBAL PROPERTY target_list)
# add_install_option must be a macro, if put in a function, the option does
# not exists right after being declared.
macro(add_install_option target)
string(TOUPPER ${target} TGT)
option(CONFIG_INSTALL_${TGT} "Install ${TGT}" ON)
get_property(tmp GLOBAL PROPERTY target_list)
list(APPEND tmp CONFIG_INSTALL_${TGT})
set_property(GLOBAL PROPERTY target_list ${tmp})
endmacro()
function(install_target_wrapper target)
add_install_option(${target})
if(CONFIG_INSTALL_${TGT})
# message("CONFIG_INSTALL_${TGT}=${CONFIG_INSTALL_${TGT}}")
install(TARGETS ${target}
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
COMPONENT application
)
endif()
endfunction()
function(generate_install_config)
set(CONF "${CMAKE_BINARY_DIR}/InstallConfig.cmake")
file(WRITE "${CONF}" "# Automatically generated install config file.
Copy this file and edit to customize the installation.\n")
file(APPEND "${CONF}" "# Use to populate the initial cmake cache: cmake
-C InstallConfigForCustomer.cmake\n")
file(APPEND "${CONF}" "# EDIT VARIABLES BELOW\n")
get_property(tmp GLOBAL PROPERTY target_list)
list(SORT tmp)
foreach(ITEM ${tmp})
file(APPEND ${CONF} "set(${ITEM}_VALUE ${${ITEM}})\n")
endforeach()
file(APPEND "${CONF}" "#\n# DO NOT EDIT BELOW\n#\n")
foreach(ITEM ${tmp})
file(APPEND ${CONF} "set(${ITEM} \${${ITEM}_VALUE} CACHE BOOL
\"Install ${ITEM}\" FORCE)\n")
endforeach()
list(LENGTH tmp tmp_len)
message("-- Number of targets: ${tmp_len}")
endfunction()
Le mer. 25 juil. 2018 à 02:09, Jason Heeris a
écrit :
> My project consists of a lot of "module" style targets (static libraries,
> more or less), but only a few top-level targets that a user would actually
> want to build. The "all" target is empty, that is, every target has
> "EXCLUDE_FROM_ALL" set. The user will, at compile time, decide to build
> whichever target they need. A single target may depend on a couple of
> others, so the end result of a single target being built might be eg. an
> exe file plus a dll plus a couple of other things.
>
> But I also want to provide installation capabilities, so users don't have
> to hunt down exes and libs scattered throughout CMake's build tree. I might
> want to create installers using CPack at some point too.
>
> How do I do this if all of my targets are EXCLUDE_FROM_ALL? According to
> the documentation, even if I use the OPTIONAL flag in install(), the
> behaviour is undefined. Better not do that.
>
> The only other option I see is to create custom commands (POST_BUILD
> style) for every target that copies it to some designated output directory.
> But then I can't take advantage of CMake's other installation capabilities,
> and I think that would be invisible to CPack.
>
> Is there some other way?
>
> I'm using CMake 3.12 on Windows 10/Ubuntu 18.04, if that's relevant.
>
> Cheers,
> Jason
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
--
Francis Giraldeau
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How to specify library dir for imported interface?
Le mer. 4 juil. 2018 à 10:43, Marc CHEVRIER a écrit : > Next version of CMake (3.13) will supports properties LINK_OPTIONS as well > as INTERFACE_LINK_OPTIONS. > Interesting, will it fix the issue with pkg-config? When installed in a non-standard directory, pkg-config will return the library dir. Here is an example with libsodium: $ PKG_CONFIG_PATH=/tmp/bidon/lib/pkgconfig pkg-config --libs libsodium -L/tmp/bidon/lib -lsodium At first, the property INTERFACE_LINK_DIRECTORIES would make sens. Would there be some drawbacks to specify link directories for imported targets? Cheers, Francis -- Francis Giraldeau -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] How to specify library dir for imported interface?
> However, it seems no property exists to actually specify the library dir > of imported target, nor the linker flags to pass when using the > imported target. > > What would be the best way to specify the library dir for an imported > library? My workarround at the moment is to add a global link_directories(). It is not clean, as it lacks the transitivity for library users, but at least it works. Cheers, Francis -- Francis Giraldeau -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] How to specify library dir for imported interface?
Build fails at link time, because a static library imported using
pkg-config is not in the standard path:
[ 74%] Linking CXX executable valhalla_add_predicted_traffic
/usr/bin/c++ ... -lprime_server ...
Usually, cmake uses the absolute path to the static library, but instead,
pkg-config provides the library name and the library dir separately. Here
is the imported target:
add_library(libprime_server INTERFACE IMPORTED)
pkg_check_modules(libprime_server REQUIRED libprime_server>=0.6.3)
set_target_properties(libprime_server PROPERTIES
INTERFACE_LINK_LIBRARIES "${libprime_server_LIBRARIES}"
INTERFACE_INCLUDE_DIRECTORIES "${libprime_server_INCLUDE_DIRS}")
The library dir is defined in the CMakeCache.txt (both in the LDFLAGS in
LIBRARY_DIRS):
libprime_server_LDFLAGS:INTERNAL=-L/home/francis/local/lib;-lprime_server
libprime_server_LIBRARY_DIRS:INTERNAL=/home/francis/local/lib
However, it seems no property exists to actually specify the library dir of
imported target, nor the linker flags to pass when using the imported
target.
What would be the best way to specify the library dir for an imported
library?
Thanks!
Francis Giraldeau
--
Francis Giraldeau
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Why isn't target_link_libraries not enough in some cases?
> Hi,
>
> I am fetching and building SDL2 using FetchContent and then using
> target_link_libraries(MyExe SDL2) in the hopes that the required include
> directories and libraries will be added populated properly. The example
> project can be found here:
>
> https://github.com/samaursa/cmake_fetch_content_SDL2
>
> Unfortunately, it seems that I have to manually specify the include
> directories. Although target_link_directories(...) does take care of the
> linking against the correct libraries. When it comes to my own CMake
> enabled libraries, I do not have to specify the include directories.
The SDL add_library() only specify the include directory for install
target:
target_link_libraries(SDL2 ${EXTRA_LIBS} ${EXTRA_LDFLAGS})
target_include_directories(SDL2 PUBLIC $)
They themselves include directories using the old global includes instead
of target specific includes:
include_directories(${SDL2_BINARY_DIR}/include ${SDL2_SOURCE_DIR}/include)
There should be a target_include_directories(SDL2 PUBLIC
<$BUILD_INTERFACE:${SDL2_SOURCE_DIR}/include), but that must be in the same
CMakeLists that defines the library, which require changing the SDL's
CMakeLists.
So, one solution could be to create an imported target to attach this path
and l ink to it instead:
add_library(SDL2x INTERFACE IMPORTED)
set_target_properties(SDL2x PROPERTIES INTERFACE_INCLUDE_DIRECTORIES
"${sdl2_SOURCE_DIR}/include")
set_target_properties(SDL2x PROPERTIES INTERFACE_LINK_LIBRARIES SDL2)
Tested with CMake 3.11. However, to make it work, I had to add OpenGL:
find_package(OpenGL REQUIRED)
target_link_libraries(testExe SDL2x OpenGL::GL)
Install fails, but that's another issue (the symlink is created in the
wrong directory) and this should be reported to SDL I guess.
CMake Error at _deps/sdl2-build/cmake_install.cmake:188 (file):
file INSTALL cannot find
"[...]/build/_deps/sdl2-build/libSDL2.so".
Call Stack (most recent call first):
cmake_install.cmake:42 (include)
Francis
--
Francis Giraldeau
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
