[CMake] problem with ADD_SUBDIRECTORY always inheriting all settings

Eric Noulard eric.noulard at gmail.com
Wed Feb 2 02:47:12 EST 2011


2011/2/1 Maarten Nieber <hallomaarten at yahoo.com>:
> Hi everybody,
> I´m mailing to find out what the community thinks of my feature request
> (http://public.kitware.com/Bug/view.php?id=5974), which was unfortunately
> rejected, and maybe come up with a better idea that serves the same goal.
> However, first I want to say that I appreciate the effort that the CMake
> team is putting in this free software. If my feature request really doesn't
> make it into CMake, so be it :-)
> The plea that I would like to make is that the core functionality of CMake
> is to set up the compilation environment, and therefore CMake should avoid
> restrictions on which environments you can create. The current problem I see
> with ADD_SUBDIRECTORY is that you can create a solution with all your
> projects, but it does not give you full control of your environment: child
> projects will always inherit all settings from parent projects, including
> the ones they don't need or don't want.

Then may the child is not child but a sibling.
If projB should not inherit from projA then projB should'nt be a child
of projA but probably a sibling.

> A workaround was proposed: let all child projects depend on an empty parent
> project. This however will not work, because I'm depending on
> ADD_SUBDIRECTORY to create the >real< dependency structure of my project, as
> this structure will affect build order and linker dependencies (in fact, I
> don't think that ADD_SUBDIRECTORY should create a linker dependency either,
> but this is a related but different issue).
> My point of view is that CMake should allow you to create exactly the
> project dependency structure you require (it already does a good job on
> this), with the option to completely control the most common compilation
> environment variables (library paths, defines, source paths, etc) of every
> project.

Then Dave was right. The top level proj must be almost empty
and all other project should be sibbling.
Then you use add_dependencies in order to setup the dependencies you want.

> My proposal for the DONT_INHERIT keyword basically means that you
> either let CMake do most of the work (DONT_INHERIT = false), which makes
> life easy but doesn't give full control, OR that you put DONT_INHERIT = true
> and then you have to do more work yourself (but with complete control). In
> my opinion, this added flexibility is worth the possible confusion caused by
> DONT_INHERIT overruling cached values.
> If you have an alternative idea about how to achieve these goals, I'd like
> to hear about it.

If youd don't want to INHERIT something from your parent then
your parent should'nt be your parent :-]

Let me rephrase the question in another way:

Why would you want to use add_subdirectory WITHOUT inheriting?
What do you want to keep from add_subdirectory in this case?


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


More information about the CMake mailing list