[CMake] add_subdirectory inheritance (patch)

irukandji irukandji at voidptr.eu
Thu Apr 19 09:16:41 EDT 2012 

Change it to whatever you want :) Search and replace is for me much 
easyer
then to workaround the inheritance :)

regards,
irukandji

On 2012-04-19 14:56, David Cole wrote:
> If that's the case then "NOINHERIT" is not the correct name for this.
> (Because that, to me, primarily implies CMake variable value
> inheritance, and directory properties, and everything that inherits.)
>
>
>
> On Thu, Apr 19, 2012 at 8:48 AM, irukandji <irukandji at voidptr.eu> 
> wrote:
>> 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