[CMake] add_subdirectory inheritance

[irukandji]

> 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