[CMake] Advice on how to remove duplicated code for object and interface library setup
I am trying to obey modern CMake target-based practices, with a twist that
everything is available as an OBJECT library if desired. I have this working
and can explain why if desired, but I feel it is extraneous for this question.
What I create:
- mylib <- the main library
- mylib_obj <- contains all of the actual objects for the library (OBJECT
library)
- mylib_interface <- linked with mylib
So it looks like this:
add_library(mylib_obj OBJECT "")
add_library(mylib_interface INTERFACE)
Based on various options / settings, target_sources(mylib_obj) will be set and
all of the various compiler operations etc. At the end, I have
# MYLIB_LIBRARY_TYPE is either SHARED or STATIC
add_library(mylib ${MYLIB_LIBRARY_TYPE} $)
target_link_libraries(mylib mylib_interface)
This works nicely, but internally I have to do the same operations for both
mylib_obj and mylib_interface.
target_include_directories(mylib_obj PUBLIC ${SomeLib_INCLUDE_DIRS})
target_include_directories(mylib_interface INTERFACE
${SomeLib_INCLUDE_DIRS})
target_link_libraries(mylib_interface INTERFACE ${SomeLib_LIBRARIES})
Without mylib_interface, I cannot include the future linking information as
well as include / compiler directive information will not be propagated with
target_link_libraries(something mylib). But mylib_obj also needs include
information, etc. But I can’t do
target_link_libraries(mylib_obj mylib_interface)
because mylib_obj is an object library.
Is there a way to avoid having to set the same thing for both mylib_obj and
mylib_interface given the requirement that mylib_obj is intended to house all
of the actual objects?
Thank you for any guidance, I’m sorry if this question doesn’t make much sense.
I’m trying to unlearn all of my outdated self-taught CMake!
-Stephen
--
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] Link-Time Dependency Injection for Unit Tests
2018-03-15 14:52 GMT+01:00 Joshua Baergen : > Thanks Eric! That worked perfectly. > > I had looked at generator expressions yesterday, but didn't understand at > which point during makefile generation they were evaluated, and had falsely > assumed that they were evaluated too early. Happy to learn new tricks! :) > You're welcome. -- Eric -- 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] Link-Time Dependency Injection for Unit Tests
Thanks Eric! That worked perfectly. I had looked at generator expressions yesterday, but didn't understand at which point during makefile generation they were evaluated, and had falsely assumed that they were evaluated too early. Happy to learn new tricks! :) Josh On Thu, Mar 15, 2018 at 2:56 AM Eric Noulard wrote: > Hi Joshua, > > > 2018-03-15 4:18 GMT+01:00 Joshua Baergen : > >> Hello, >> >> I'm attempting to implement link-time dependency injection. In brief, >> what this means is that, for a library A that depends on B, we would >> normally have: >> >> target_link_libraries(A B) >> >> However, when building unittests for A (done in a subdirectory), we >> instead want: >> >> target_link_libraries(A MockB) >> >> I've spent a bunch of time looking through CMake documentation and I'm >> not sure how to express this without resorting to manually specifying the >> link line when A is in use. Could someone give me some guidance? >> > > > Since you want link-time choice I bet you should have a look to some kind > of generator expression > see doc here: > https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html > > genex may be used in target_link_libraries. > > for example if you can set some property on (all) your unit test target > (I personnally do that globally by defining my own mytest_add_executable > macro) > > set_target_properties( PROPERTIES UNITTEST 1) > > then may be you can use some genex which check whether an executable if a > unitest: > > set(GenEx_IsTest $,1>) > > and then use some other genex using the previous one in > target_link_libraries > > like here for automatic instantiation of source: > https://cmake.org/pipermail/cmake/2015-January/059669.html > > I lack time to craft the complete example but I think it's doable with > genex. > > It seems that others already played along this line: > https://developer.blender.org/T46725 > > -- > Eric > -- 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] managed targeted code requires a '/clr' option cmake fix
Hey Guys, Just wanted to find out if there is a way to fix the "*managed targeted code requires a '/clr' option*" error while compiling. The problem is ,this projects has C# dependency. It uses #using(.dll). In VS configuration project settings this can be given but how do you do it using CMake? Please share if you guys know the solution to resolve the issue. -- -- 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] Incremental builds with ExternalProject_Add
Dear All, I ran into an issue with incremental builds that use ExternalProject_Add(...), which I'm very surprised isn't a more widely advertised issue. So I thought I'd ask here if people are aware of this behaviour... For our software projects we build a good number of externals using separate "externals project". https://gitlab.cern.ch/atlas/atlasexternals Most of these externals we build by downloading tar files of their sources from various locations, and building those. Like for instance: https://gitlab.cern.ch/atlas/atlasexternals/blob/master/External/ROOT/CMakeLists.txt (Just to demonstrate how not trivial some of these builds already are...) With one of the latest updates of this repository I started seeing some very unnerving compilation errors in our CI system, which lead me to realise that we've been using ExternalProject_Add(...) in a way so far that's fundamentally not CI compatible. Let's take an example where I have two versions of an external. Let's download these versions in files external-1.0.0.tar.gz, and external-1.0.1.tar.gz. And let's assume that version 1.0.0 was created in January, while 1.0.1 in February of some year. Now, if we just create a very simple ExternalProject_Add(...) configuration, that will just not be incremental build compatible in this setup. Since let's just walk through the build steps. - Let's say that it's March by now. - We first build version 1.0.0 of the external. When ExternalProject_Add(...) unpacks external-1.0.0.tar.gz, the source directory of this project will have modification dates from January. The built files on the other hand will have modification dates from March. (The current date.) - Now we update our build to use version 1.0.1 of the external. When ExternalProject_Add(...) unpacks external-1.0.1.tar.gz, the source files get updated to have modification dates from February. But remember, the build results have a modification date from March. So any reasonable build system that external-1.0.1.tar.gz may use, will not do anything. It will assume that the files in the build directory are already up to date. Of course the issue is even worse when we try to downgrade the version of the external in an update of our own repository. So my question is: Are people not running into this issue all the time? For now I'm thinking of solving this problem like: https://gitlab.cern.ch/akraszna/IncrementalBuildTest/blob/master/CMakeLists.txt Which is a quite drastic approach, but I don't know of a better one. And I wonder if ExternalProject_Add(...) should just behave like this out of the box by default. That whenever it downloads/unpacks a different version of an external than it built before, it should always purge the previous build completely. What does everybody think about this? Am I missing something? Have I been using ExternalProject_Add(...) wrong all along? Cheers, Attila -- 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] Link-Time Dependency Injection for Unit Tests
Hi Joshua, 2018-03-15 4:18 GMT+01:00 Joshua Baergen : > Hello, > > I'm attempting to implement link-time dependency injection. In brief, what > this means is that, for a library A that depends on B, we would normally > have: > > target_link_libraries(A B) > > However, when building unittests for A (done in a subdirectory), we > instead want: > > target_link_libraries(A MockB) > > I've spent a bunch of time looking through CMake documentation and I'm not > sure how to express this without resorting to manually specifying the link > line when A is in use. Could someone give me some guidance? > Since you want link-time choice I bet you should have a look to some kind of generator expression see doc here: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html genex may be used in target_link_libraries. for example if you can set some property on (all) your unit test target (I personnally do that globally by defining my own mytest_add_executable macro) set_target_properties( PROPERTIES UNITTEST 1) then may be you can use some genex which check whether an executable if a unitest: set(GenEx_IsTest $,1>) and then use some other genex using the previous one in target_link_libraries like here for automatic instantiation of source: https://cmake.org/pipermail/cmake/2015-January/059669.html I lack time to craft the complete example but I think it's doable with genex. It seems that others already played along this line: https://developer.blender.org/T46725 -- Eric -- 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
