[CMake] add_subdirectory inheritance (patch)

irukandji irukandji at voidptr.eu
Thu Apr 19 08:48:11 EDT 2012 

What my thought was:

if you are adding the subdirectory, you want to keep what is stored 
within
the cmake variables so you can fine grain what to use and not to use in
subdirectory or pass just some settings from caller, if this would be 
also
removed there would be no way to pass anything to subdirectory.

Also the system directories are kept (as they are considered system 
wide).
Evertything else is not copyed (void 
cmMakefile::InitializeFromParent()).

(some code reviewing from your side wouldnt be a bad idea, i have 
checked
what is passed and what not using debugger so this should work, there 
is
always a possibility i have missed something i am not aware of)

Regards,
irukandji

On 2012-04-19 12:10, David Cole wrote:
> So, wait. This intends to avoid inheritance of preprocessor, compiler
> and linker stuff, but it still allows inheritance of all other
> directory properties and CMake variable values...?
>
>
> On Thu, Apr 19, 2012 at 5:04 AM, irukandji <irukandji at voidptr.eu> 
> wrote:
>> Ok, guys, catch... source base is 2.8.7.
>>
>> add_subdirectory(source_dir [binary_dir]
>>                   [EXCLUDE_FROM_ALL] [NOINHERIT])
>>
>>
>> /.../
>>
>> If the NOINHERIT argument is provided, the subdirectory build 
>> configuration
>> will not inherit any preprocessor, compiler or linker specific 
>> parameters.
>>
>> Regards,
>> irukandji
>>
>>
>>
>> On 2012-04-18 21:07, irukandji wrote:
>>>
>>> I appreciate the idea but my view is that if the solution (whatever
>>> dev. solution)
>>> is not elegant there is something wrong with it.
>>>
>>> While testing the posibilities, i had it, i have implemented the
>>> optional dont_inherit
>>> flag to add_subdirectory. Tomorrow (some testing first), I'll 
>>> submit
>>> a patch, i hope it
>>> will be accepted as it is completely unintrusive, backward
>>> compatible, <insert the casual
>>> buzzwords>,...
>>>
>>> Regards,
>>> irukandji
>>>
>>> On 2012-04-18 18:18, Kent Williams wrote:
>>>>
>>>> I think I understand what you're trying to do better now.  It's a 
>>>> bit
>>>> off the beaten path for CMake, and has more moving parts than is
>>>> strictly necessary.
>>>>
>>>> It could be set up as a nested suite of ExternalProjects, and 
>>>> avoid
>>>> the definitions inheritance issue you're running into.
>>>>
>>>> You could also manage this by having a flag that is defined if 
>>>> this is
>>>> a top-level build and not defined in a standalone build, and using
>>>> Source Properties to properly set the definitions for the files 
>>>> that
>>>> need different flags.
>>>>
>>>> The problem is that ADD_DEFINITIONS is global for the current 
>>>> project,
>>>>  It is also -- for that very reason -- if not a deprecated CMake
>>>> feature, one whose use is discouraged.  You're much better off 
>>>> using
>>>> SET_SOURCE_FILE_PROPERTIES to handle this kind of configuration 
>>>> trick,
>>>> since the properties are tied to a particular source file.  You 
>>>> can
>>>> use macros and FOREACH to avoid having to call
>>>> SET_SOURCE_FILE_PROPERTIES on every file explicitly.
>>>>
>>>> You have become invested in the idea that it can only be done by
>>>> changing CMake, but you can do it without changing CMake if you 
>>>> get
>>>> creative with the tools already available to you.
>>>>
>>>> On Tue, Apr 17, 2012 at 5:02 PM, irukandji <irukandji at voidptr.eu> 
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Maybe i can try to reexplain, from head, ignore syntactic errors 
>>>>> and
>>>>> oversimplifying...
>>>>> **********************************
>>>>> /sources/cmakelist.txt
>>>>>
>>>>> /sources/binaries/helloworld
>>>>> ..................cmakelists.txt
>>>>>
>>>>> /sources/binaries/hellocmake
>>>>> ..................cmakelists.txt
>>>>>
>>>>> /sources/libraries/stdio
>>>>> ..................cmakelists.txt
>>>>> ..................description.txt
>>>>>
>>>>> /sources/libraries/gfx
>>>>> ..................cmakelists.txt
>>>>> ..................description.txt
>>>>> **********************************
>>>>>>>
>>>>>>>
>>>>>>> helloworld: <<
>>>>>
>>>>>
>>>>> project(helloworld)
>>>>> include("${libs}/stdio/description.txt")
>>>>> include("${libs}/network/description.txt")
>>>>> file(glob da_files "*.*")
>>>>> add_executable( helloworld da_files )
>>>>> helper_add_stdio()
>>>>> **********************************
>>>>>>>
>>>>>>>
>>>>>>> stdio description <<
>>>>>
>>>>>
>>>>> function (helper_add_stdio)
>>>>> include_directory( "${sources}/libraries/stdio" )
>>>>> target_add_library( ${CMAKE_PROJECT_NAME} 
>>>>> "${BINDIR}/whatever/stdio.lib"
>>>>> )
>>>>> add_definition( -DUSING_STDIO )
>>>>> ...
>>>>> execute(grab_me_a_beer_and_add_some_more_flags)
>>>>> ...
>>>>> if(not exists "${BINDIR}/whatever/stdio.lib")
>>>>> add_subdirectory( "/sources/libraries/stdio")
>>>>> endif()
>>>>> endfunction()
>>>>> **********************************
>>>>>>>
>>>>>>>
>>>>>>> hellocmake <<
>>>>>
>>>>>
>>>>> project(hellocmake)
>>>>> include("${libs}/gfx/description.txt")
>>>>> include("${libs}/network/description.txt")
>>>>> file(glob da_files "*.*")
>>>>> add_executable( hellocmake da_files )
>>>>> helper_add_gfx()
>>>>> helper_add_stdio()
>>>>> **********************************
>>>>>>>
>>>>>>>
>>>>>>> gfx description <<
>>>>>
>>>>>
>>>>> function (helper_add_gfx)
>>>>> include_directory( "${sources}/libraries/gfx" )
>>>>> target_add_library( ${CMAKE_PROJECT_NAME} 
>>>>> "${BINDIR}/whatever/gfx.lib" )
>>>>> add_definition( -DUSING_GFX )
>>>>> ...
>>>>> if(not exists "${BINDIR}/whatever/gfx.lib")
>>>>> add_subdirectory( "${sources}/libraries/gfx"
>>>>> "${BINDIR}/whatever/gfx.lib" )
>>>>> endif()
>>>>> endfunction()
>>>>> **********************************
>>>>>>>
>>>>>>>
>>>>>>> sources/cmakelist.txt <<
>>>>>
>>>>>
>>>>> add_subdirectory( "/sources/binaries/helloworld" )
>>>>> add_subdirectory( "/sources/binaries/hellocmake" )
>>>>> **********************************
>>>>>
>>>>> * If i run cmake on helloworld, lets say for windows, i get 
>>>>> solution and
>>>>> vcprojs
>>>>> of helloworld with dependancy to generated vcproj for stdio. 
>>>>> Stand
>>>>> alone.
>>>>>
>>>>> * If i run cmake on hellocmake, lets say for windows, i get 
>>>>> solution and
>>>>> vcprojs
>>>>> of hellocmake with dependancy to generated vcproj for stdio and 
>>>>> gfx.
>>>>> Stand
>>>>> alone.
>>>>>
>>>>> * If i run cmake on /sources/cmakelist.txt i get full build.
>>>>>
>>>>> * The author(s) of helloworld doesnt need to have a clue about 
>>>>> stdio
>>>>> library
>>>>> its paths
>>>>> or whatever as the author(s) of stdio/description.txt has 
>>>>> prepared
>>>>> everything for him
>>>>> (in a perfect world :) ). Same goes for hellocmake.
>>>>>
>>>>> * The full build doesnt need to understand what is behind the 
>>>>> helloworld
>>>>> and
>>>>> hellocmake as
>>>>> they both will take care about building the dependancies on their 
>>>>> own.
>>>>>
>>>>> * The coupling is minimized.
>>>>>
>>>>> * The description.txt can serve as a hook in case of changing 
>>>>> whatever
>>>>> settings for
>>>>> the libraries (from renaming them, to changing directory tree, 
>>>>> changing
>>>>> compiler flags etc)
>>>>>
>>>>> This is what i would like to achieve. But if you look at >> 
>>>>> hellocmake
>>>>> <<,
>>>>> the
>>>>> stdio cmakelists will inherit the include path from gfx library 
>>>>> which
>>>>> you
>>>>> really
>>>>> dont want. It will also inherit -DUSING_GFX even if it has 
>>>>> nothing to do
>>>>> with it.
>>>>>
>>>>> Regards,
>>>>> irukandji
>>>>>
>>>>>
>>>>>
>>>>> On 2012-04-17 22:56, irukandji wrote:
>>>>>>>
>>>>>>>
>>>>>>> I don't know how you'd ever maintain a sane overall project if 
>>>>>>> it
>>>>>>> depends on each subdirectory having conflicting compiler flags.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Well here is the fun, there is not something like "you", we are 
>>>>>> taling
>>>>>> about
>>>>>> over 100 developers and if everyone is handling his own garden, 
>>>>>> this is
>>>>>> not
>>>>>> a problem. I cant tell you the details (the lawyers stuff) but 
>>>>>> believe
>>>>>> me
>>>>>> it
>>>>>> is as sane as it can be in regards of doing insane things :)
>>>>>>
>>>>>> I'll check your suggestions tomorrow, thank you.
>>>>>>
>>>>>> Regards,
>>>>>> irukandji
>>>>>>
>>>>>> On 2012-04-17 20:54, Kent Williams wrote:
>>>>>>>
>>>>>>>
>>>>>>> I think then that you shouldn't use add_subdirectory.
>>>>>>>
>>>>>>> I'd suggest using the ExternalProject module in this case, 
>>>>>>> because it
>>>>>>> uncouples the subdirectory's project from the parent project. 
>>>>>>>  In that
>>>>>>> case, each subdirectory can be its own project and maintain 
>>>>>>> private
>>>>>>> configurations.
>>>>>>>
>>>>>>> You can manage dependencies between ExternalProjects with the 
>>>>>>> DEPENDS
>>>>>>> keyword.
>>>>>>>
>>>>>>> I think that what you're describing doesn't really make any 
>>>>>>> sense to
>>>>>>> me.  I don't know how you'd ever maintain a sane overall 
>>>>>>> project if it
>>>>>>> depends on each subdirectory having conflicting compiler flags.
>>>>>>>
>>>>>>> Another way you can manage this sort of thing is to use Source 
>>>>>>> file
>>>>>>> properties -- see SET_SOURCE_FILE_PROPERTIES in the CMake
>>>>>>> documentation and the "Properties on Source Files" section as 
>>>>>>> well.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 17, 2012 at 1:27 PM, irukandji 
>>>>>>> <irukandji at voidptr.eu>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Oh, hi :)
>>>>>>>>
>>>>>>>> Well, the add_subdirectory takes all the preprocessor defines 
>>>>>>>> and
>>>>>>>> include/library
>>>>>>>> paths defined before calling it into the added "subdirectory"
>>>>>>>> cmakelists.txt.
>>>>>>>>
>>>>>>>> If cmakelists.txt A defines -DWhatever and calls 
>>>>>>>> add_subdirectory(/B)
>>>>>>>> where
>>>>>>>> the
>>>>>>>> cmakelists.txt for building library B resides then the library 
>>>>>>>> B is
>>>>>>>> going to
>>>>>>>> be
>>>>>>>> built with -DWhatever. This is probably great behaviour for 
>>>>>>>> some
>>>>>>>> cases
>>>>>>>> but
>>>>>>>> can
>>>>>>>> also be undesired:
>>>>>>>> in my case, each library has its own description file, 
>>>>>>>> residing in
>>>>>>>> same
>>>>>>>> directory
>>>>>>>> as its cmakelists.txt, with only one function, which is 
>>>>>>>> included and
>>>>>>>> called
>>>>>>>> with few
>>>>>>>> parameters to specify runtime etc. by each binary which has a
>>>>>>>> dependancy
>>>>>>>> to
>>>>>>>> library.
>>>>>>>> The description file function sets the -I to itself for 
>>>>>>>> caller, the
>>>>>>>> -l
>>>>>>>> to
>>>>>>>> its output
>>>>>>>> and, if the output file is not found, also calls 
>>>>>>>> add_subdirectory on
>>>>>>>> its
>>>>>>>> own
>>>>>>>> directory.
>>>>>>>>
>>>>>>>> This is a perfect situation for developers as we can just do 
>>>>>>>> out of
>>>>>>>> source
>>>>>>>> configuration
>>>>>>>> for whatever directory (where project resides) and only the
>>>>>>>> dependancy
>>>>>>>> tree
>>>>>>>> for that
>>>>>>>> particular binary is built.
>>>>>>>>
>>>>>>>> It also brings additional benefit that the team which takes 
>>>>>>>> care
>>>>>>>> about
>>>>>>>> specific
>>>>>>>> library also takes care for description file and needed 
>>>>>>>> defines which
>>>>>>>> splits
>>>>>>>> the
>>>>>>>> ownership of projects and also presents a single point of 
>>>>>>>> inclusion
>>>>>>>> for
>>>>>>>> that
>>>>>>>> particular
>>>>>>>> library, meaning only one file has to be changed for library
>>>>>>>> specializations.
>>>>>>>>
>>>>>>>> For the nightly builds, only executables are added to the 
>>>>>>>> build while
>>>>>>>> everything
>>>>>>>> else is built only if actually used.
>>>>>>>>
>>>>>>>> It works great, but the add_subdirectory is propagating the 
>>>>>>>> settings
>>>>>>>> from
>>>>>>>> executable
>>>>>>>> to dependant libraries and messes the build.
>>>>>>>>
>>>>>>>> The question actually is: can i workaround this behaviour and 
>>>>>>>> if not,
>>>>>>>> can
>>>>>>>> you please
>>>>>>>> include the parameter to add_subdirectory function to NOT 
>>>>>>>> propagate
>>>>>>>> the
>>>>>>>> settings.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Irukandji
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2012-04-17 17:58, Kent Williams wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Frankly, I don't entirely understand what the problem is, or 
>>>>>>>>> what
>>>>>>>>> your
>>>>>>>>> proposed solution is.
>>>>>>>>>
>>>>>>>>> What is it that you don't want the subdirectory context to 
>>>>>>>>> inherit?
>>>>>>>>>
>>>>>>>>> On Tue, Apr 17, 2012 at 10:30 AM, irukandji 
>>>>>>>>> <irukandji at voidptr.eu>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> (as no one answered to my previous email, let me add this:
>>>>>>>>>> multiplatform
>>>>>>>>>> project with few million lines
>>>>>>>>>> of code, sheer size of the project is not allowing to turn 
>>>>>>>>>> around
>>>>>>>>>> whole
>>>>>>>>>> directory tree as price / performance
>>>>>>>>>> is a very relevant factor and even rewriting 
>>>>>>>>>> makefiles/vcprojs to
>>>>>>>>>> cmake
>>>>>>>>>> will
>>>>>>>>>> take months)
>>>>>>>>>>
>>>>>>>>>> The add_subdirectory inheritance striked which is 
>>>>>>>>>> practically a
>>>>>>>>>> show
>>>>>>>>>> stopper, it was already discussed here
>>>>>>>>>> http://www.mail-archive.com/cmake@cmake.org/msg34291.html 
>>>>>>>>>> What was
>>>>>>>>>> proposed
>>>>>>>>>> (DONT_INHERIT) was a great idea
>>>>>>>>>> and improvement to versability of CMake and also harmless 
>>>>>>>>>> for
>>>>>>>>>> backward
>>>>>>>>>> compatibility so i dont really
>>>>>>>>>> understand why forcing subproject to inherit all the 
>>>>>>>>>> settings.
>>>>>>>>>>
>>>>>>>>>> Yes, what is added with add_subdirectory is not a child but 
>>>>>>>>>> a
>>>>>>>>>> sibling
>>>>>>>>>> or
>>>>>>>>>> even some other part of the tree
>>>>>>>>>> but the point is that it doesnt stop the cmake from building 
>>>>>>>>>> it
>>>>>>>>>> correctly
>>>>>>>>>> but this inheritance is a problem
>>>>>>>>>> as it adds include directories to wrong versions of headers 
>>>>>>>>>> in
>>>>>>>>>> public
>>>>>>>>>> libs
>>>>>>>>>> (due to bugs in different versions,
>>>>>>>>>> affecting different platforms,... the unification is 
>>>>>>>>>> impossible),
>>>>>>>>>> the
>>>>>>>>>> flags
>>>>>>>>>> are used on wrong places etc.
>>>>>>>>>>
>>>>>>>>>> Is there a way to workaround it?
>>>>>>>>>>
>>>>>>>>>> Thank you.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>
>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>
>>>>>>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>>>>>>
>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake

More information about the CMake mailing list