Re: [CMake] add_subdirectory inheritance (patch)
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
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
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, ,...
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
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_N
Re: [CMake] add_subdirectory inheritance (patch)
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 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 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, >>> 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
> 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 "${BI
Re: [CMake] add_subdirectory inheritance (patch)
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
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, ,...
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
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 hellowor
Re: [CMake] add_subdirectory inheritance (patch)
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 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, > 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 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.
Re: [CMake] add_subdirectory inheritance (patch)
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, ,...
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
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 achi
Re: [CMake] add_subdirectory inheritance
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,
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
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
d
Re: [CMake] add_subdirectory inheritance
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 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
Re: [CMake] add_subdirectory inheritance
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
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 b
Re: [CMake] add_subdirectory inheritance
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 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 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
Re: [CMake] add_subdirectory inheritance
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 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 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/lis
Re: [CMake] add_subdirectory inheritance
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 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
