Re: [CMake] ADD_CUSTOM_COMMAND and how to include generated files from other directories
On 02/17/2008 04:51 PM, Mike Jackson wrote:
Lets assume for a second that your layout is something like:
Project
src
-sub1
--CMakeLists.txt
--sub1.cpp
--sub1.ui
-sub2
--CMakeLists.txt
--sub2.cpp
What you would want quite possible is a top level CMakeLists.txt file
Like this:
PROJECT (MyGreatProject)
SET (LIBRARY_OUTPUT_PATH "${PROJECT_BINARY_DIR}/Bin" CACHE INTERNAL
"For libraries.")
SET (EXECUTABLE_OUTPUT_PATH "${PROJECT_BINARY_DIR}/Bin" CACHE
INTERNAL "For executables.")
#--- All the generated .h and .cpp files end up in $
{CMAKE_CURRENT_BINARY_DIR}
#--- so include that directory.
INCLUDE_DIRECTORIES( "${CMAKE_CURRENT_BINARY_DIR}" )
ADD_SUBDIRECTORY( src/sub1)
ADD_SUBDIRECTORY( src/sub2)
#--- End CMakeLists.txt file
The above _should_ work although I just did it from memory.
Mike Jackson
Thanks for your replay. But no, this doesn't work. This goes along with
what Alex just wrote back - include_directory behaves like normal
variables. Setting
INCLUDE_DIRECTORIES( "${CMAKE_CURRENT_BINARY_DIR}" )
just works for the directory you're currently at and the directories
beneath it - but not for those above or on the same level.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ADD_CUSTOM_COMMAND and how to include generated files from other directories
On 02/17/2008 04:58 PM, Alexander Neundorf wrote:
On Sunday 17 February 2008, blinkeye wrote:
Hi guys
I'm in the process of replacing Makefiles from two large projects with
CMake files. So far it's working great, but now I hit a wall:
I need to generate .cpp and .h files from input files (analogue to the
.ui files of Qt).
...
Imagine the following project layout:
src
-sub1
--CMakeLists.txt
--sub1.cpp
--sub1.ui
-sub2
--CMakeLists.txt
--sub2.cpp
${QT_UIC_EXECUTABLE} will read sub1.ui and generate a file like
"ui_sub1.h". sub1.cpp and sub2.cpp both include the file "ui_sub1.h".
While above macro works for sub1 it doesn't work for sub2:
make
[ 20%] Generating ui_sub1.h
[ 40%] Generating moc_sub1.cxx
Scanning dependencies of target sub1
[ 60%] Building CXX object src/sub1/CMakeFiles/sub1.dir/sub1.o
[ 80%] Building CXX object src/sub1/CMakeFiles/sub1.dir/moc_sub1.o
Linking CXX executable sub1
[ 80%] Built target sub1
Scanning dependencies of target sub2
[100%] Building CXX object src/sub2/CMakeFiles/sub2.dir/sub2.o
/home/cerberos/Desktop/mutacts/dan/src/sub2/sub2.cpp:4:21: error:
ui_sub1.h: No such file or directory make[2]: ***
[src/sub2/CMakeFiles/sub2.dir/sub2.o] Error 1
make[1]: *** [src/sub2/CMakeFiles/sub2.dir/all] Error 2
make: *** [all] Error 2
I tried for hours but I can't figure out a proper (or at least working)
way on how to achieve that. Changing above macro to include the path of
the generated header files doesn't seem to make a difference:
MACRO (QT4_WRAP_UI_CUSTOM outfiles )
FOREACH (it ${ARGN})
GET_FILENAME_COMPONENT(outfile ${it} NAME_WE)
GET_FILENAME_COMPONENT(infile ${it} ABSOLUTE)
SET(outfile ${CMAKE_CURRENT_BINARY_DIR}/ui_${outfile}.h)
include_directories( ${CMAKE_CURRENT_BINARY_DIR} )
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${QT_UIC_EXECUTABLE}
ARGS -o ${outfile} ${infile}
MAIN_DEPENDENCY ${infile})
SET(${outfiles} ${${outfiles}} ${outfile})
ENDFOREACH (it)
ENDMACRO (QT4_WRAP_UI_CUSTOM)
For some reason the included directory is lost in sub2 again (btw: is
there a way to log the currently included directories besides analysing
the make output?).
In that respect include directories work the same way as variables, they are
per directory, i.e. a sub directory inherits all the include dirs of its
parent directory, but the include directories of a subdir don't influence the
parent dir.
Did you try to put something like the following into sub2/CMakeLists.txt ?
include_directories(${CMAKE_BINARY_DIR}/sub1)
Alex
>
Thanks for your prompt reply. Hmm, you're right, of course
include_directories works like variables. Adding
include_directories(${CMAKE_BINARY_DIR}/sub1)
seems to work, so much for "not to see the wood for the trees". Will try
it at work tomorrow with the real codebase.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to prevent relinking targets with shared libraries
Hi guys I'm getting along very well (and quickly!) with porting two large projects from Makefiles to CMake. Actually, 3 projects will follow later on (and possibly more). Yeah, CMake is actually THAT great. I just wanted to share my delight and acknowledgement of this tool, it makes developing C/C++ code just more fun. Back to the topic: I wonder if it isn't possible to prevent relinking targets with a shared library if you didn't change any interface? Isn't this one of the reason for using shared libraries? I implemented a switch for either creating static libraries (like it used to be with the old Makefiles) or shared libraries. At the moment I'm just creating plain .so libs, without any version number (so far I didn't happen to come across a shared library tutorial with cmake), maybe this is the problem? Does cmake support such a versioning and would that resolve the relinking? Regards ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to prevent relinking targets with shared libraries
On Thu, February 21, 2008 22:23, Alan W. Irwin wrote:
> On 2008-02-21 21:57+0100 blinkeye wrote:
>
>> [...]At the moment I'm just creating plain .so libs, without any
>> version number (so far I didn't happen to come across a shared library
>> tutorial with cmake), maybe this is the problem? Does cmake support such a
>> versioning and would that resolve the relinking?
>
> There is full support for shared libraries (at least on my Linux platform).
>
> Look at the documentation of SET_TARGET_PROPERTIES (especially where
> it mentions VERSION, SOVERSION, and RPATH.)
>
Great, thanks for the hint. So, I set a VERSION and SOVERSION on my library:
add_library( mylib SHARED ${SRCS} )
set_target_properties( mylib PROPERTIES VERSION 1 SOVERSION 1 )
But still, any change to 'mylib' requires all targets linked against 'mylib' to
be
relinked again ...
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to prevent relinking targets with shared libraries
On Fri, February 22, 2008 10:07, Bill Hoffman wrote:
> BlinkEye wrote:
>> On Thu, February 21, 2008 22:23, Alan W. Irwin wrote:
>>> On 2008-02-21 21:57+0100 blinkeye wrote:
>>>> [...]At the moment I'm just creating plain .so libs, without any version
>>>> number
(so far I didn't happen to come across a shared library tutorial with cmake),
maybe this is the problem? Does cmake support such a versioning and would that
resolve the relinking?
>>> There is full support for shared libraries (at least on my Linux platform).
>>> Look
at the documentation of SET_TARGET_PROPERTIES (especially where it mentions
VERSION, SOVERSION, and RPATH.)
>> Great, thanks for the hint. So, I set a VERSION and SOVERSION on my library:
add_library( mylib SHARED ${SRCS} )
>> set_target_properties( mylib PROPERTIES VERSION 1 SOVERSION 1 ) But still,
>> any
change to 'mylib' requires all targets linked against 'mylib' to
be
>> relinked again ...
> No, I don't think so. I don't see how CMake can tell if the interface
> changed or
not. How did the makefiles do that?
>
> -Bill
>
Hmm, ok, scenario: I download cmake-2.4.8.tar.gz and built it from source. The
finale cmake executable is linked against:
# ldd bin/cmake
linux-gate.so.1 => (0xb7f4b000)
libdl.so.2 => /lib/libdl.so.2 (0xb7f2d000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
(0xb7e5)
libm.so.6 => /lib/libm.so.6 (0xb7e2a000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1
(0xb7e2)
libc.so.6 => /lib/libc.so.6 (0xb7cf)
/lib/ld-linux.so.2 (0xb7f4c000)
I can touch (change the timestamp) of say '/lib/libc.so.6' and execute make
withou
cmake getting relinked again. This is the desired effect I try to achieve.
CMake/Make cannot know anything about interface changes - this is where we
developers create a new shared library version if this happens. But if I fix
some
minor bug in say mylib.so.1 and mytarget is linked against mylib.so.1 I try to
prevent mytarget to get relinked. I guess the problem is that the libs are built
from within the project itself because I merely have to touch mylib (change the
timestamp) and cmake will relink all targets ...
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Enable warnings
>> On 2/24/08, David Sveningsson <[EMAIL PROTECTED]> wrote: Hi, I'm quite new with cmake and I can't figure out how to enable warnings for the generated makefiles/projects. For instance, I would like to use the -Wall flag with gcc. like that for example: set( CMAKE_C_FLAGS "-fstack-protector -fstack-protector-all" ) set( CMAKE_C_FLAGS_DEBUG "-O2 -Wall -ggdb" ) set( CMAKE_C_FLAGS_RELEASE "-Os -Wall" ) set( CMAKE_CXX_FLAGS "-fstack-protector -fstack-protector-all" ) set( CMAKE_CXX_FLAGS_DEBUG "-O2 -Wall -ggdb" ) set( CMAKE_CXX_FLAGS_RELEASE "-Os -Wall" ) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Enable warnings
On Mon, February 25, 2008 11:11, dizzy wrote: > On Sunday 24 February 2008 23:22:58 blinkeye wrote: >> >> On 2/24/08, David Sveningsson <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi, I'm quite new with cmake and I can't figure out how to enable >> >> warnings for the generated makefiles/projects. For instance, I would >> >> like to use the -Wall flag with gcc. >> >> like that for example: >> >> set( CMAKE_C_FLAGS "-fstack-protector -fstack-protector-all" ) >> set( CMAKE_C_FLAGS_DEBUG "-O2 -Wall -ggdb" ) >> set( CMAKE_C_FLAGS_RELEASE "-Os -Wall" ) >> >> set( CMAKE_CXX_FLAGS "-fstack-protector -fstack-protector-all" ) >> set( CMAKE_CXX_FLAGS_DEBUG "-O2 -Wall -ggdb" ) >> set( CMAKE_CXX_FLAGS_RELEASE "-Os -Wall" ) > > That looks fairly unportable (how do you make sure your compiler supports > those flags? if it doesn't it won't compile at all which is not probably what > you want since you are using cmake I supose you want it portable). > > I prefer first to detect supported compiler arguments with > CheckCXXCompilerFlag() and if yes add it to the CFLAGS of targets using > SET_TARGET_PROPERTIES(target PROPERTIES COMPILE_FLAGS ...) (and if one wants > to share several flags among many targets, put the flags in some variables > and expand the variables in the SET_TARGET_PROPERTIES commands). > That's not very portable, true. But you understand the problem of the OP, do you? He's new to cmake and he was asking on how to set compiler specific flags. Even though your answers not wrong it doesn't help him at all. And no, cmake isn't used just because it's portable. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Having problems getting started
I guess the following would suit your needs too:
# AUX_SOURCE_DIRECTORY: Find all source files in a directory.
AUX_SOURCE_DIRECTORY(dir VARIABLE)
Collects the names of all the source files in the specified directory
and stores the list in the variable provided. This command is intended
to be used by projects that use explicit template instantiation.
Template instantiation files can be stored in a "Templates" subdirectory
and collected automatically using this command to avoid manually listing
all instantiations.
It is tempting to use this command to avoid writing the list of source
files for a library or executable target. While this seems to work,
there is no way for CMake to generate a build system that knows when a
new source file has been added. Normally the generated build system
knows when it needs to rerun CMake because the CMakeLists.txt file is
modified to add a new source. When the source is just added to the
directory without modifying this file, one would have to manually rerun
CMake to generate a build system incorporating the new file.
On 02/29/2008 07:47 PM, Arlen Cox wrote:
Thanks Mike.
That was exactly what I was looking for.
-Arlen
On Fri, Feb 29, 2008 at 11:20 AM, Mike Jackson <[EMAIL PROTECTED]>
wrote:
You may want to look at the
file(GLOB variable [RELATIVE path] [globbing expressions]...)
or
file(GLOB_RECURSE variable [RELATIVE path]
[globbing expressions]...)
if you do a cmake --help-command file a print out of the documentation
for that command will be listed.
Also,
Some projects use the following as the way to get source files:
SET (MyProject_SRCS SomeFile.cpp SomeOtherFile.cxx lib/SomeLibFile.cpp
)
ADD_LIBRARY(VSEngine ${MyProject_SRCS})
That will default to a static library. If you want a shared library:
ADD_LIBRARY(VSEngine SHARED ${MyProject_SRCS})
--
Mike Jackson
On Feb 29, 2008, at 11:37 AM, Arlen Cox wrote:
1. Is there some way to use wildcards when specifying files for a
library? Something like this:
add_library(VSEngine *.cpp)
That particular line doesn't work. I tried, but there must be a way that
I can add a file to a project without having to modify the makefil
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Selecting DEBUG and RELEASE Builds in Linux
On Tue, March 4, 2008 11:27, Malhotra, Anupam wrote: > CMAKE_BUILD_TYPE is not initialized with a readable value at > configuration time. This is because the user is free to select a build > type at build time. Now in visual studio 6/visual studio 8 2005 we can > select the build type by selecting Debug/Release after opening the > workspace/solution. But how can the same be achieved in Linux? After my > makefiles are generated using cmake, I want to first build the Debug > mode and then the release mode. But how do I select which build type to > select while building? Please advise. > Create a build directory containing both a debug and release dir like: my_project/debug my_project/release enter my_project/debug and init the project like usual ( cmake path_to_my_project ). execute # make edit_cache and change or set CMAKE_BUILD_TYPE to "Debug". hit [c], [e] and [g] to configure, exit and generate appropriate makefiles and start building. enter my_project/release and do the same steps except set CMAKE_BUILD_TYPE to "Release". ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Selecting DEBUG and RELEASE Builds in Linux
I guess you missed my answer yesterday ... If I'm not mistaken calling just cmake path_to_your_project_srcs doesn't set the BUILD_TYPE to anything. What about the following: % cd build/your_project/debug; % cmake path_to_project_srcs -DCMAKE_BUILD_TYPE=DEBUG % cd build/your_project/release % cmake path_to_project_srcs -DCMAKE_BUILD_TYPE=RELEASE You could easily create aliases for these 2 commands, like: alias cmakedebug='cmake $1 -DCMAKE_BUILD_TYPE=DEBUG' alias cmakerelease='cmake $1 -DCMAKE_BUILD_TYPE=RELEASE' which would be used like: % cd build/your_project/debug % cmakedebug path_to_project_srcs or % cd build/your_project/release % cmakerelease path_to_project_srcs respectively. To set a default build type I suggest the following: if( NOT CMAKE_BUILD_TYPE ) set( CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel." FORCE ) endif() This will just overwrite the CMAKE_BUILD_TYPE if it has not been set. On Wed, March 5, 2008 07:02, Malhotra, Anupam wrote: > Hi David > > Thanks for the help. I understood your solution but I want your help to > implement this solution in my project. I am automating the entire build > process which does not require any manual intervention. Now to achieve > this after writing all my CMakeLists.txt files, I just give the command, > > "cmake ." > > > > in the source directory. This creates all the relevant makefiles. Now > my question is: > > > > 1.What is the default BUILD TYPE if we are not changing anything? > 2.Is there a way if we can set the BUILD TYPE in my CMakeLists.txt > so that after giving the command "cmake ." at the command prompt, I get > the particular build type set in my makefiles? > > > > Thanks and Regards > > Anupam Malhotra > > > > > > From: David Cole [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2008 6:23 PM > To: Malhotra, Anupam > Cc: cmake@cmake.org > Subject: Re: [CMake] Selecting DEBUG and RELEASE Builds in Linux > > > > With a make file generator, you do set CMAKE_BUILD_TYPE to Debug or > Release at configure time. Then, if you want both builds, you need to > have two build trees, one configured for Debug, the other for Release. > The part of the Wiki you are referring to only applies to IDEs that have > their own project files that manage multiple configurations at build > time, like Visual Studio and Xcode. > > > HTH, > David > > > > On 3/4/08, Malhotra, Anupam <[EMAIL PROTECTED]> wrote: > > Hi > > > > I read on the CMake wiki page that: > > > > CMAKE_BUILD_TYPE is not initialized with a readable value at > configuration time. This is because the user is free to select a build > type at build time. Now in visual studio 6/visual studio 8 2005 we can > select the build type by selecting Debug/Release after opening the > workspace/solution. But how can the same be achieved in Linux? After my > makefiles are generated using cmake, I want to first build the Debug > mode and then the release mode. But how do I select which build type to > select while building? Please advise. > > > > Thanks and Regards > > Anupam Malhotra > > > > The information contained in this electronic mail transmission > > may be privileged and confidential, and therefore, protected > > from disclosure. If you have received this communication in > > error, please notify us immediately by replying to this > > > > > message and deleting it from your computer without copying > > or disclosing it. > > > > > > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > > > > > The information contained in this electronic mail transmission > may be privileged and confidential, and therefore, protected > from disclosure. If you have received this communication in > error, please notify us immediately by replying to this > message and deleting it from your computer without copying > or disclosing it. > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake // how to find out compiler version in CMakeLists.txt
On 03/09/2008 09:18 AM, Sergey Nik wrote: Hi all, I'm looking information how I can determinate GCC version in my CMakeLists.txt script. After short searching mail list archive I've not found something relevant. Is it possible? Thank you in advance, Sergey A combination of EXECUTE_PROCESS and 'gcc -dumpversion' is what you're looking for. IIRC: EXECUTE_PROCESS( COMMAND gcc -dumpversion GCC_VERSION ) where GCC_VERSION will be the variable the result is saved in. After that you'll probably want to make a STRING operation (NOTEQUAL, LESS, GREATER and so on) with GCC_VERSION ... ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting Makefiles sensitive tonew/deleted files/directories?
On 03/19/2008 09:50 PM, Ken Martin wrote:
> Can you do the glob, configure the result out to a file, then INCLUDE
that
> file. I believe that will solve the problem. Something like
>
> file(GLOB SRC *.cpp)
> configure_file(somefile.in somefile)
> include(somefile)
>
> where somefile.in looks like
>
> # list of files as a comment -- ${SRC}
>
> This works because CMake does check (at make time) to see if any included
> file in CMake has changed but is smart in that configure_file only writes
> the file if it has changed. I'm pretty sure something like that will
work.
>
> Ken
Could you be a bit more specific on how to include a file with listed
source files or actually in which format such a file has to be? I tried
that but it didn't work for me. Alex was suggesting this solution a
while back where packadal was asking about "build shared library from
static libraries":
You have to set them in the parent directory or set them ibn a file in the
subdir which is then INCLUDE()d in the parent directory (use full paths
then)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cpack -G DEB for subdirectories
Hello I seem not able to find an example of how to generate .deb files with cpack for different subdirectories of a project. Is this possible and if so, how? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack -G DEB for subdirectories
On Fri, January 30, 2009 14:37, Eric Noulard wrote: > As far as I know CPack only handles a single per-project package, > i.e. you may easilly build a package (deb, rpm, tgz etc...) for the WHOLE > project, even if the project does have subdirectories. > CPack will package all target, files etc... which are > Thanks for elaborating and answering my question. I'm actually trying to generate different .deb files for a single project (e.g. for different libraries, executables). Checking out your links it looks like this is not possible at the moment. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack -G DEB for subdirectories
> You may want to use custom CPack scripts for different purposes. By default, > CPack uses script generated by CMake in top-level directory, but you can > write your own one (and as many as you want) and pass it to cpack as command > line parameter. > Of course, install components could be great help in packaging. > I take it you're talking about the '--config' option. That sounds like a workaround if it's possible to use/include some globals to reduce the overhead. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] get the relative path of current directory
Use case:
You start developing src/prototype1 which implements feature X. Next, you copy
src/prototype1 to src/prototype2 and implement feature Y or enhance feature X.
You don't branch because you're constantly comparing these prototypes against
each others (say for speed).
To make this really easy I need a way of getting the ${RELATIVE_SOURCE_DIR} of
such a prototype so I can copy src/prototype1 to src/prototypeX without
adjusting src/prototypeX/CMakeLists.txt:
set( EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin/${RELATIVE_SOURCE_DIR} )
So, the only thing one needs to adjust is the project's top CMakeLists.txt and
add the new prototype's source dir to the SUBDIRS directive.
Is this possible?
___
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_DIRECTORIES and UNIX style separated environment variables
Hi guys
I'm not able to convince cmake to properly use an environment variable which
consists of more than one entry for the INCLUDE_DIRECTORIES directive. It always
takes the value as it is:
Passing
MY_SPECIAL_INCLUDE32=/foo/bar/32bit/include:/foo/bar/include
to INCLUDE_DIRECTORIES like
INCLUDE_DIRECTORIES( "$ENV{MY_SPECIAL_INCLUDE32}" )
results in
/usr/bin/c++ -I/foo/bar/32bit/include:/foo/bar/include ...
instead of
/usr/bin/c++ -I/foo/bar/32bit/include -I/foo/bar/include ...
The same applies for LINK_DIRECTORIES but this seems not to matter for the rpath
command.
I tried to use TO_CMAKE_PATH with no avail.
Any ideas?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE_DIRECTORIES and UNIX style separated environment variables
On 09/18/2007 06:09 PM, Alexander Neundorf wrote:
On Tuesday 18 September 2007 11:35, BlinkEye wrote:
Hi guys
I'm not able to convince cmake to properly use an environment variable
which consists of more than one entry for the INCLUDE_DIRECTORIES
directive. It always takes the value as it is:
Passing
MY_SPECIAL_INCLUDE32=/foo/bar/32bit/include:/foo/bar/include
to INCLUDE_DIRECTORIES like
INCLUDE_DIRECTORIES( "$ENV{MY_SPECIAL_INCLUDE32}" )
results in
/usr/bin/c++ -I/foo/bar/32bit/include:/foo/bar/include ...
instead of
/usr/bin/c++ -I/foo/bar/32bit/include -I/foo/bar/include ...
The same applies for LINK_DIRECTORIES but this seems not to matter for the
rpath command.
I tried to use TO_CMAKE_PATH with no avail.
This should work. Can you please post the example and the results ?
Alex
Yeah, sure:
This won't work:
export DELTA_ROOT=/foo/bar/delta3d_1.5.0_64bit
export DELTA_DATA=$DELTA_ROOT/data
export DELTA_INC=$DELTA_ROOT/inc
export DELTA_INC_EXT=$DELTA_ROOT/ext/inc
export
DELTA_LIB=$DELTA_ROOT/lib:$DELTA_ROOT/ext/lib:$DELTA_ROOT/ext/lib64:$DELTA_ROOT/ext/lib64/osgPlugins
#export DELTA_LIB=$DELTA_ROOT/lib
#export DELTA_LIB_EXT=$DELTA_ROOT/ext/lib
#export DELTA_LIB_EXT64=$DELTA_ROOT/ext/lib64
#export DELTA_LIB_EXT64_OSG=$DELTA_ROOT/ext/lib64/osgPlugins
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DELTA_LIB:$DELTA_LIB_EXT:$DELTA_LIB_EXT64:$DELTA_LIB_EXT64_OSG
INCLUDE_DIRECTORIES( "$ENV{DELTA_INC}" "$ENV{DELTA_INC_EXT}" )
#LINK_DIRECTORIES( "$ENV{DELTA_LIB}" )
LINK_DIRECTORIES( "$ENV{DELTA_LIB}" "$ENV{DELTA_LIB_EXT}" "$ENV{DELTA_LIB_EXT64}" )
ADD_EXECUTABLE( prototype prototype.cpp )
TARGET_LINK_LIBRARIES( prototype dtCore dtABC dtUtil dtTerrain dtDAL
osgProducer )
# DON'T remove! This one is necessary or delta3d applications segfault
ADD_DEFINITIONS( -DSIGSLOT_PURE_ISO )
ADD_DEFINITIONS( -ggdb )
/usr/bin/cmake -H/foo/bar/svn/proj/src/prototype5
-B/foo/bar/svn/proj/src/prototype5 --check-build-system
CMakeFiles/Makefile.cmake 0
-- Configuring done
-- Generating done
-- Build files have been written to: /foo/bar/svn/proj/src/prototype5
/usr/bin/cmake -E cmake_progress_start
/foo/bar/svn/proj/src/prototype5/CMakeFiles 1
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/foo/bar/svn/proj/src/prototype5'
make -f CMakeFiles/prototype.dir/build.make CMakeFiles/prototype.dir/depend
make[2]: Entering directory `/foo/bar/svn/proj/src/prototype5'
make[2]: Nothing to be done for `CMakeFiles/prototype.dir/depend'.
make[2]: Leaving directory `/foo/bar/svn/proj/src/prototype5'
make -f CMakeFiles/prototype.dir/build.make CMakeFiles/prototype.dir/build
make[2]: Entering directory `/foo/bar/svn/proj/src/prototype5'
Linking CXX executable prototype
/usr/bin/cmake -P CMakeFiles/prototype.dir/cmake_clean_target.cmake
/usr/bin/c++ -fPIC "CMakeFiles/prototype.dir/prototype.o" -o prototype
-rdynamic
-L/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/lib:/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/ext/lib:/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/ext/lib64:/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/ext/lib64/osgPlugins
-ldtCore -ldtABC -ldtUtil -ldtTerrain -ldtDAL -losgProducer
-Wl,-rpath,/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/lib:/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/ext/lib:/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/ext/lib64:/foo/bar/svn/proj/src/delta3d_1.5.0_64bit/ext/lib64/osgPlugins
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -ldtCore
collect2: ld returned 1 exit status
make[2]: *** [prototype] Error 1
make[2]: Leaving directory `/foo/bar/svn/proj/src/prototype5'
make[1]: *** [CMakeFiles/prototype.dir/all] Error 2
make[1]: Leaving directory `/foo/bar/svn/proj/src/prototype5'
make: *** [all] Error 2
Whereas the following does work:
export DELTA_ROOT=/foo/bar/delta3d_1.5.0_64bit
export DELTA_DATA=$DELTA_ROOT/data
export DELTA_INC=$DELTA_ROOT/inc
export DELTA_INC_EXT=$DELTA_ROOT/ext/inc
#export
DELTA_LIB=$DELTA_ROOT/lib:$DELTA_ROOT/ext/lib:$DELTA_ROOT/ext/lib64:$DELTA_ROOT/ext/lib64/osgPlugins
export DELTA_LIB=$DELTA_ROOT/lib
export DELTA_LIB_EXT=$DELTA_ROOT/ext/lib
export DELTA_LIB_EXT64=$DELTA_ROOT/ext/lib64
export DELTA_LIB_EXT64_OSG=$DELTA_ROOT/ext/lib64/osgPlugins
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DELTA_LIB:$DELTA_LIB_EXT:$DELTA_LIB_EXT64:$DELTA_LIB_EXT64_OSG
INCLUDE_DIRECTORIES( "$ENV{DELTA_INC}" "$ENV{DELTA_INC_EXT}" )
#LINK_DIRECTORIES( "$ENV{DELTA_LIB}" )
LINK_DIRECTORIES( "$ENV{DELTA_LIB}" "$ENV{DELTA_LIB_EXT}" "$ENV{DELTA_LIB_EXT64}" )
ADD_EXECUTABLE( prototype prototype.cpp )
TARGET_LINK_LIBRARIES( prototype dtCore dtABC dtUtil dtTerrain dtDAL
osgProducer )
# DON'T remove! This one is necessary or delta3d applications segfault
ADD_DEFINITIONS( -DSIGSLOT_PURE_ISO )
ADD_DEFINITIONS( -ggdb )
/usr/bin/cmake
Re: [CMake] Debug buildtype broken
On Wed, September 19, 2007 14:32, Bill Hoffman wrote: > Andreas Pakulat wrote: >> Hi, >> >> yesterday I noticed that the Debug buildtype has the same problems as >> the --enable-debug option in autohell. Its not possible to properly >> debug an application that has been built with CMAKE_BUILD_TYPE=Debug. >> At least not with Unix Makefile's (possibly the same applies to MinGW >> Makefile's but I didn't check that). The problem is the compiler flags >> that are set in this build mode: >> >> -g -O2 >> > I don't think that CMake does that. If you do CMAKE_BUILD_TYPE=Debug it > just does > -g. > > IF(CMAKE_COMPILER_IS_GNUCC) > SET (CMAKE_C_FLAGS_INIT "") > SET (CMAKE_C_FLAGS_DEBUG_INIT "-g") > > > > Could you be setting -g -O2 in CFLAGS or CXXFLAGS environment > variables before running cmake? > > -Bill > Since we're talking about debug symbols I suggest to take a look at: http://www.gentoo.org/proj/en/qa/backtraces.xml In short, the preferred way for debugging with gdb/gcc seems to be: -ggdb -O2 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE_DIRECTORIES and UNIX style separated environment variables
On Thu, September 20, 2007 19:34, kitts wrote:
> On Tuesday 18 Sep 2007 10:31:25 pm blinkeye wrote:
>> >> I'm not able to convince cmake to properly use an environment variable
>> >> which consists of more than one entry for the INCLUDE_DIRECTORIES
>> >> directive. It always takes the value as it is:
>> >>
>> >> Passing
>> >>
>> >> MY_SPECIAL_INCLUDE32=/foo/bar/32bit/include:/foo/bar/include
>> >>
>> >> to INCLUDE_DIRECTORIES like
>> >>
>> >> INCLUDE_DIRECTORIES( "$ENV{MY_SPECIAL_INCLUDE32}" )
>> >>
>> >> results in
>> >>
>> >> /usr/bin/c++ -I/foo/bar/32bit/include:/foo/bar/include ...
>> >>
>> >> instead of
>> >>
>> >> /usr/bin/c++ -I/foo/bar/32bit/include -I/foo/bar/include ...
>
> What happens if you do not include the quotes?
>
> INCLUDE_DIRECTORIES( $ENV{MY_SPECIAL_INCLUDE32} )
>
> Just a guess... Maybe the quotes are making it assume the whole as a single
> string.
> --
> Cheers!
> kitts
>
Thanks for the reply, but this doesn't work neither.
I wonder if I'm the only one who ran into what appears to be a very basic issue.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE_DIRECTORIES and UNIX style separated environment variables
On 09/20/2007 09:00 PM, Bill Hoffman wrote: BlinkEye wrote: Thanks for the reply, but this doesn't work neither. I wonder if I'm the only one who ran into what appears to be a very basic issue. Basically, you are using cmake incorrectly. You should not be using environment variables in a cmake project directly. You should only use them for place for FIND_* to look for things. You should not depend on having the environment set before running cmake. You are asking for trouble with builds. For example: 1/ setenv ; cmake ; make 2 cvs update 3 start a new shell and forget the setenv 4. make (this runs cmake because a file changed in the cvs update) , it creates new makefiles that don't work. CMake should be used to cache variables that store locations of include and library paths that were discovered by cmake. -Bill Hmm, I see, good point. The thing is that I started to use it like this since I have 64bit and 32bit systems and couldn't figure out how to distinct that for the CMakeLists.txt, because depending on the ARCH libs and includes are differently. But it's true, using the env is error prone. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE_DIRECTORIES and UNIX style separated environment variables
On 09/20/2007 09:18 PM, Bill Hoffman wrote: ... That said, FILE(TO_CMAKE_PATH ...) should work just fine, please post an example that does not work. -Bill On 09/20/2007 09:15 PM, Alexander Neundorf wrote: >... > I still don't see a FILE(TO_CMAKE_PATH ...) in the example. > > Alex Hi guys, thanks for your replies. You're right, FILE(TO_CMAKE_PATH ...) works. I misunderstood this function. Sorry for the noise. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target_link_libraries external library
On 09/21/2007 10:15 PM, Juan Sanchez wrote: Hello, How do you add an externally library for linking into a target? I am getting something like this from TARGET_LINK_LIBRARIES? CMake Error: Attempt to add link library "/bar/linux-x86/opt/foo.a" to target "waterlooApps" which is not built by this project. Thanks, Juan This happens if you mix the executable names. If your subproject is say prototype1 the following will return the above error: ADD_EXECUTABLE( prototype1 prototype1.cpp ) TARGET_LINK_LIBRARIES( prototype3 libfoo ) You have to write ADD_EXECUTABLE( prototype1 prototype1.cpp ) TARGET_LINK_LIBRARIES( prototype1 libfoo ) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
