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 <[email protected]>
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 <[email protected]>
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
<[email protected]>
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/[email protected]/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
diff -Naur ..\..\cmake-2.8.7.original\Source\cmAddSubDirectoryCommand.cxx .\cmAddSubDirectoryCommand.cxx
--- ..\..\cmake-2.8.7.original\Source\cmAddSubDirectoryCommand.cxx Fri Dec 30 12:17:16 2011
+++ .\cmAddSubDirectoryCommand.cxx Thu Apr 19 10:02:22 2012
@@ -26,6 +26,7 @@
std::string binArg;
bool excludeFromAll = false;
+ bool inheritFromParent = true;
// process the rest of the arguments looking for optional args
std::vector<std::string>::const_iterator i = args.begin();
@@ -37,6 +38,11 @@
excludeFromAll = true;
continue;
}
+ else if( *i == "NOINHERIT" )
+ {
+ inheritFromParent = false;
+ continue;
+ }
else if (!binArg.size())
{
binArg = *i;
@@ -117,7 +123,7 @@
// Add the subdirectory using the computed full paths.
this->Makefile->AddSubDirectory(srcPath.c_str(), binPath.c_str(),
- excludeFromAll, false, true);
+ excludeFromAll, false, true, inheritFromParent);
return true;
}
diff -Naur ..\..\cmake-2.8.7.original\Source\cmMakefile.cxx .\cmMakefile.cxx
--- ..\..\cmake-2.8.7.original\Source\cmMakefile.cxx Fri Dec 30 12:17:18 2011
+++ .\cmMakefile.cxx Thu Apr 19 10:56:41 2012
@@ -49,7 +49,7 @@
};
// default is not to be building executables
-cmMakefile::cmMakefile(): Internal(new Internals)
+cmMakefile::cmMakefile(): Internal(new Internals), m_NoInheritanceFromParent(false)
{
const cmDefinitions& defs = cmDefinitions();
const std::set<cmStdString> globalKeys = defs.LocalKeys();
@@ -1478,9 +1478,14 @@
this->Internal->VarStack.top() = parent->Internal->VarStack.top().Closure();
// copy include paths
- this->IncludeDirectories = parent->IncludeDirectories;
this->SystemIncludeDirectories = parent->SystemIncludeDirectories;
+ // We dont want to inherit parrent settings so bailing out
+ if( false == GetInheritanceFromParent() )
+ return;
+
+ this->IncludeDirectories = parent->IncludeDirectories;
+
// define flags
this->DefineFlags = parent->DefineFlags;
this->DefineFlagsOrig = parent->DefineFlagsOrig;
@@ -1574,7 +1579,7 @@
void cmMakefile::AddSubDirectory(const char* srcPath, const char *binPath,
bool excludeFromAll, bool preorder,
- bool immediate)
+ bool immediate, bool inheritFromParent /* = true */)
{
// Make sure the binary directory is unique.
if(!this->EnforceUniqueDir(srcPath, binPath))
@@ -1587,6 +1592,8 @@
this->LocalGenerator->GetGlobalGenerator()->CreateLocalGenerator();
lg2->SetParent(this->LocalGenerator);
this->LocalGenerator->GetGlobalGenerator()->AddLocalGenerator(lg2);
+
+ lg2->GetMakefile()->SetInheritanceFromParent( inheritFromParent );
// set the subdirs start dirs
lg2->GetMakefile()->SetStartDirectory(srcPath);
diff -Naur ..\..\cmake-2.8.7.original\Source\cmMakefile.h .\cmMakefile.h
--- ..\..\cmake-2.8.7.original\Source\cmMakefile.h Fri Dec 30 12:17:18 2011
+++ .\cmMakefile.h Wed Apr 18 13:34:00 2012
@@ -270,7 +270,7 @@
bool preorder = false);
void AddSubDirectory(const char* fullSrcDir,const char *fullBinDir,
bool excludeFromAll, bool preorder,
- bool immediate);
+ bool immediate, bool inheritFromParent = true);
/**
* Configure a subdirectory
@@ -1002,6 +1002,12 @@
// Enforce rules about CMakeLists.txt files.
void EnforceDirectoryLevelRules();
+
+public:
+ inline bool GetInheritanceFromParent() const { return m_NoInheritanceFromParent; }
+ inline void SetInheritanceFromParent( bool inherit ){ m_NoInheritanceFromParent = inherit; }
+protected:
+ bool m_NoInheritanceFromParent;
};
//----------------------------------------------------------------------------
--
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
