Re: [CMake] Include-Dir order problem
On Wed, Feb 16, 2011 at 2:32 AM, Andreas Pakulat ap...@gmx.de wrote:
On 16.02.11 03:48:03, Michael Hertling wrote:
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
On 15.02.11 17:54:29, Michael Hertling wrote:
On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
Hi,
I've got a somewhat tricky problem here with include directories. I'm
building a couple of source files and for some of them I need to add
an
include-directory to the front of the list that cmake passes to the
compiler. At the same time other source files in that directory need
to
not have that include-dir in front of the list.
I can't see a way to do this, except by using COMPILE_FLAGS source
file
properties for each and every file to specify include-dirs and not
use
include_directories at all, as COMPILE_FLAGS always end up behind the
includes.
So, am I missing something here? If not I guess I'll have to find
that
bugreport about making include-dirs a source-file property and vote
for
it so it gets included into 2.8.5...
Currently, AFAIK, it's not possible to set source-file-specific
include
directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
the shortcoming you've mentioned. Probably, the really clean solution
ATM would be a reorganisation of the sources, but I doubt if the need
for different include directories is an appropriate criterion for a
project's directory layout.
Well, all those sources need to be in the same target, so I can't quite
see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){f();return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the main target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for main.
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library.
Exactly my case.
Most probably, you don't want an additional libsub.so, so you would
need to compile f.c at least with -fPIC as COMPILE_FLAGS to get
further along with a static library. Alternatively, you might use a
RULE_LAUNCH_LINK property in order to capture the object files from
the subdirectory and incorporate them in the actual target, see [1].
However, then you would be restricted to a Makefile generator. IMO,
none of these appoaches is really convincing why one should aim at an
INCLUDE_DIRECTORIES source file and target property.
Unfortunately it seems Brad is unwilling to implement this unless it can
be done 'properly' for all generators. Which is sad, but for now I could
solve this with local special header files which are used by those cpp
files that would otherwise need the extra directory in front.
In my opinion, this is not sad, but commendable. I *hate* the features of
CMake that only work with generator a, b and c, but not the rest of them.
Features of CMake that only work under *some* circumstances are frustrating
to deal with at best.
Andreas
--
Your object is to save the world, while still leading a pleasant life.
___
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
Re: [CMake] Include-Dir order problem
On 16.02.11 07:03:32, David Cole wrote:
On Wed, Feb 16, 2011 at 2:32 AM, Andreas Pakulat ap...@gmx.de wrote:
On 16.02.11 03:48:03, Michael Hertling wrote:
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
On 15.02.11 17:54:29, Michael Hertling wrote:
On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
Hi,
I've got a somewhat tricky problem here with include directories. I'm
building a couple of source files and for some of them I need to add
an
include-directory to the front of the list that cmake passes to the
compiler. At the same time other source files in that directory need
to
not have that include-dir in front of the list.
I can't see a way to do this, except by using COMPILE_FLAGS source
file
properties for each and every file to specify include-dirs and not
use
include_directories at all, as COMPILE_FLAGS always end up behind the
includes.
So, am I missing something here? If not I guess I'll have to find
that
bugreport about making include-dirs a source-file property and vote
for
it so it gets included into 2.8.5...
Currently, AFAIK, it's not possible to set source-file-specific
include
directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
the shortcoming you've mentioned. Probably, the really clean solution
ATM would be a reorganisation of the sources, but I doubt if the need
for different include directories is an appropriate criterion for a
project's directory layout.
Well, all those sources need to be in the same target, so I can't quite
see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){f();return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the main target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for main.
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library.
Exactly my case.
Most probably, you don't want an additional libsub.so, so you would
need to compile f.c at least with -fPIC as COMPILE_FLAGS to get
further along with a static library. Alternatively, you might use a
RULE_LAUNCH_LINK property in order to capture the object files from
the subdirectory and incorporate them in the actual target, see [1].
However, then you would be restricted to a Makefile generator. IMO,
none of these appoaches is really convincing why one should aim at an
INCLUDE_DIRECTORIES source file and target property.
Unfortunately it seems Brad is unwilling to implement this unless it can
be done 'properly' for all generators. Which is sad, but for now I could
solve this with local special header files which are used by those cpp
files that would otherwise need the extra directory in front.
In my opinion, this is not sad, but commendable. I *hate* the features of
CMake that only work with generator a, b and c, but not the rest of them.
Features of CMake that only work under *some* circumstances are frustrating
to deal with at best.
Well, I think for not-that-important features this is true, but being able
to fully control the include-dirs for a given source file (or target) is a
pretty substantial thing for a buildsystem. In addition my understanding (I
did not read all comments on the bugreport) was that adding this wouldn't
break XCode generator, it would simply mean that include-scanning wouldn't
work as well there, so the user may have to run cmake itself manually if
one of the includes in such directories changes.
Anway, apparently I'm not able to convince the people doing the work that
this should be changed, so I'll stick with yet another hack around cmake's
behaviour (until the code can be fully cleaned up).
Andreas
--
You will always get the greatest recognition for the job you least like.
___
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
Re: [CMake] Include-Dir order problem
On 02/13/2011 01:27 AM, Andreas Pakulat wrote: Hi, I've got a somewhat tricky problem here with include directories. I'm building a couple of source files and for some of them I need to add an include-directory to the front of the list that cmake passes to the compiler. At the same time other source files in that directory need to not have that include-dir in front of the list. I can't see a way to do this, except by using COMPILE_FLAGS source file properties for each and every file to specify include-dirs and not use include_directories at all, as COMPILE_FLAGS always end up behind the includes. So, am I missing something here? If not I guess I'll have to find that bugreport about making include-dirs a source-file property and vote for it so it gets included into 2.8.5... Currently, AFAIK, it's not possible to set source-file-specific include directories unless one (mis)uses COMPILE_FLAGS which is accompanied by the shortcoming you've mentioned. Probably, the really clean solution ATM would be a reorganisation of the sources, but I doubt if the need for different include directories is an appropriate criterion for a project's directory layout. If there're only a few affected files, another possible workaround consists of file-specific configured headers, i.e. find the special include directories and inject them into config'd headers that are included by the concerned source files, or even modify the latters themselves in this manner. Of course, the sources must be touched to do that. IMO, from a conceptual point of view, INCLUDE_DIRECTORIES should be also available as target and source file property, so I would vote for 1968 and 8189 - seem to be relatives - and possibly 8874, too. However, if this undertaking is addressed, one should think about how the include directories are ordered on the compiler's command line. Perhaps, there might be a convention that they appear from most to least specific, i.e. in source-target-directory order. Regards, Michael ___ 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
Re: [CMake] Include-Dir order problem
On 15.02.11 17:54:29, Michael Hertling wrote: On 02/13/2011 01:27 AM, Andreas Pakulat wrote: Hi, I've got a somewhat tricky problem here with include directories. I'm building a couple of source files and for some of them I need to add an include-directory to the front of the list that cmake passes to the compiler. At the same time other source files in that directory need to not have that include-dir in front of the list. I can't see a way to do this, except by using COMPILE_FLAGS source file properties for each and every file to specify include-dirs and not use include_directories at all, as COMPILE_FLAGS always end up behind the includes. So, am I missing something here? If not I guess I'll have to find that bugreport about making include-dirs a source-file property and vote for it so it gets included into 2.8.5... Currently, AFAIK, it's not possible to set source-file-specific include directories unless one (mis)uses COMPILE_FLAGS which is accompanied by the shortcoming you've mentioned. Probably, the really clean solution ATM would be a reorganisation of the sources, but I doubt if the need for different include directories is an appropriate criterion for a project's directory layout. Well, all those sources need to be in the same target, so I can't quite see how moving some of the sources into subdirs wuld help with that. If there're only a few affected files, another possible workaround consists of file-specific configured headers, i.e. find the special include directories and inject them into config'd headers that are included by the concerned source files, or even modify the latters themselves in this manner. Of course, the sources must be touched to do that. Thats probably the route I'm going to take as indeed there are only few files needing the extra include at the front and it'll also solve the problem of new developers in the team not realizing that the header that is included is not the one they think it is... IMO, from a conceptual point of view, INCLUDE_DIRECTORIES should be also available as target and source file property, so I would vote for 1968 and 8189 - seem to be relatives - and possibly 8874, too. However, if this undertaking is addressed, one should think about how the include directories are ordered on the compiler's command line. Perhaps, there might be a convention that they appear from most to least specific, i.e. in source-target-directory order. Thanks for digging up the bugnumbers for me. I've added my use-case there and will make sure to bring this up when the cmake devs gather input again for the next release... Andreas -- You will soon meet a person who will play an important role in your life. ___ 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
Re: [CMake] Include-Dir order problem
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
On 15.02.11 17:54:29, Michael Hertling wrote:
On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
Hi,
I've got a somewhat tricky problem here with include directories. I'm
building a couple of source files and for some of them I need to add an
include-directory to the front of the list that cmake passes to the
compiler. At the same time other source files in that directory need to
not have that include-dir in front of the list.
I can't see a way to do this, except by using COMPILE_FLAGS source file
properties for each and every file to specify include-dirs and not use
include_directories at all, as COMPILE_FLAGS always end up behind the
includes.
So, am I missing something here? If not I guess I'll have to find that
bugreport about making include-dirs a source-file property and vote for
it so it gets included into 2.8.5...
Currently, AFAIK, it's not possible to set source-file-specific include
directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
the shortcoming you've mentioned. Probably, the really clean solution
ATM would be a reorganisation of the sources, but I doubt if the need
for different include directories is an appropriate criterion for a
project's directory layout.
Well, all those sources need to be in the same target, so I can't quite
see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){f();return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the main target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for main.
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library. Most
probably, you don't want an additional libsub.so, so you would need to
compile f.c at least with -fPIC as COMPILE_FLAGS to get further along
with a static library. Alternatively, you might use a RULE_LAUNCH_LINK
property in order to capture the object files from the subdirectory and
incorporate them in the actual target, see [1]. However, then you would
be restricted to a Makefile generator. IMO, none of these appoaches is
really convincing why one should aim at an INCLUDE_DIRECTORIES source
file and target property.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34148.html
___
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
Re: [CMake] Include-Dir order problem
On 16.02.11 03:48:03, Michael Hertling wrote:
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
On 15.02.11 17:54:29, Michael Hertling wrote:
On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
Hi,
I've got a somewhat tricky problem here with include directories. I'm
building a couple of source files and for some of them I need to add an
include-directory to the front of the list that cmake passes to the
compiler. At the same time other source files in that directory need to
not have that include-dir in front of the list.
I can't see a way to do this, except by using COMPILE_FLAGS source file
properties for each and every file to specify include-dirs and not use
include_directories at all, as COMPILE_FLAGS always end up behind the
includes.
So, am I missing something here? If not I guess I'll have to find that
bugreport about making include-dirs a source-file property and vote for
it so it gets included into 2.8.5...
Currently, AFAIK, it's not possible to set source-file-specific include
directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
the shortcoming you've mentioned. Probably, the really clean solution
ATM would be a reorganisation of the sources, but I doubt if the need
for different include directories is an appropriate criterion for a
project's directory layout.
Well, all those sources need to be in the same target, so I can't quite
see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){f();return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the main target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for main.
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library.
Exactly my case.
Most probably, you don't want an additional libsub.so, so you would
need to compile f.c at least with -fPIC as COMPILE_FLAGS to get
further along with a static library. Alternatively, you might use a
RULE_LAUNCH_LINK property in order to capture the object files from
the subdirectory and incorporate them in the actual target, see [1].
However, then you would be restricted to a Makefile generator. IMO,
none of these appoaches is really convincing why one should aim at an
INCLUDE_DIRECTORIES source file and target property.
Unfortunately it seems Brad is unwilling to implement this unless it can
be done 'properly' for all generators. Which is sad, but for now I could
solve this with local special header files which are used by those cpp
files that would otherwise need the extra directory in front.
Andreas
--
Your object is to save the world, while still leading a pleasant life.
___
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
[CMake] Include-Dir order problem
Hi, I've got a somewhat tricky problem here with include directories. I'm building a couple of source files and for some of them I need to add an include-directory to the front of the list that cmake passes to the compiler. At the same time other source files in that directory need to not have that include-dir in front of the list. I can't see a way to do this, except by using COMPILE_FLAGS source file properties for each and every file to specify include-dirs and not use include_directories at all, as COMPILE_FLAGS always end up behind the includes. So, am I missing something here? If not I guess I'll have to find that bugreport about making include-dirs a source-file property and vote for it so it gets included into 2.8.5... Andreas -- Be careful! Is it classified? ___ 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
