Re: [CMake] Problem compiling with cmake 2.2.3
Betsubetsu wrote: I found out that the file CMakeFiles/IsMapVariables.dir/depend.make generated by version 2.2.3 contains the lines below while the same file generated by version 2.2.2 generated only the first 2 lines (the commented ones)! I noticed that the depend.make file is filled in with these lines at first compilation. So i removed them and compiled successfully. I did the same with all the depend.make I found and could get my executable. Are these lines necessary? I don't think so. But there are problems with these lines. The files acquisitiondatabase, global and trace_definition which should be copied by cmake do not exist. Please try to strip this down to a minimal example and submit a bug report here: http://www.cmake.org/Bug Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HowTo build one Linux binary set for all platforms?
Matt England wrote: At 4/13/2006 10:42 AM, Matt England wrote: I see that CMake does provide a single-binary set for all Linux platforms: http://www.cmake.org/files/v2.2/cmake-2.2.3-x86-linux.tar.gz How is this done? After a few days' posting and research, some references I found follow. Alas, there seems to be no clear-cut consensus. I'm still interested to know how CMake builds their one-binary-set distribution for Linux (as per above). http://www.linuxbase.org/ http://www.linuxbase.org/futures/collab/index.html http://ask.slashdot.org/article.pl?sid=05/11/24/2230256threshold=1 http://groups.google.com/group/comp.unix.programmer/browse_frm/thread/f6bd667f4f18c98c We have a least-common-denominator Linux system. We build the needed system libraries statically (such as curses). We build our own gcc using the --disable-shared configure script option to avoid getting a shared C++ library. Look in the Utilities/Release directory at the config_* files and the cmake_release.sh script for other details. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to manage different library names for release/debug ?
Silvano Imboden wrote:
I am writing (maybe another J) some cmake code
in order to compile the latest wxWindows using Cmake.
The library names should use this form
wx{platform}{version}{unicode}{debug}_{toolkit}.[lib|dll]
In CVS CMake (and soon in the upcoming 2.4 release) you can use
SET_TARGET_PROPERTIES to set a config_OUTPUT_NAME property. It will
allow a per-config name.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HowTo build one Linux binary set for all platforms?
Matt England wrote: At 4/18/2006 09:43 AM, Brad King wrote: We have a least-common-denominator Linux system. We build the needed system libraries statically (such as curses). We build our own gcc using the --disable-shared configure script option to avoid getting a shared C++ library. Look in the Utilities/Release directory at the config_* files and the cmake_release.sh script for other details. Excellent info, thanks Brad. We most likely will be migrating our builds to such a thing. I suspect the Utilities/Release files do not mention which Linux system flavor you build on. Do you guys choose a particular system for this? eg, RH 7.x...or something else? I think it's a Mandrake 10 box. There is a bit of a trick needed for CMake due to support for loaded commands. We link statically against everything but libc and libdl. In order to work with the system libc on every other machine you need to build with the oldest glibc you can find. We used to use an old glibc 2.0 system to build binaries but that old machine died so now we use a glibc 2.3 system. A few years ago that may have been a problem but no one has complained yet about needing glibc 2.3. For the few people that have such old systems they can build from source. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HowTo build one Linux binary set for all platforms?
Matt England wrote: At 4/18/2006 11:56 AM, Brad King wrote: I think it's a Mandrake 10 box. There is a bit of a trick needed for CMake due to support for loaded commands. We link statically against everything but libc and libdl. In order to work with the system libc on every other machine you need to build with the oldest glibc you can find. We used to use an old glibc 2.0 system to build binaries but that old machine died so now we use a glibc 2.3 system. A few years ago that may have been a problem but no one has complained yet about needing glibc 2.3. For the few people that have such old systems they can build from source. More excellent info, thanks again. Like my project, CMake appears to be a C++ based one. Does one need to add a c++ lib to the above list (along with libc and libdl) to the list of special libs? Presumably not, but I'm checking just to make sure. No, the C++ library can be linked statically. That is why we build GCC with the --disable-shared option. If on the other hand you have several executables that share code from big libraries then you might consider doing a shared library build which needs a different, somewhat complicated approach. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio problem with many/long additional library paths
Karr, David A (Titan) @ TITAN wrote: From: Kristian Nielsen [EMAIL PROTECTED] This generates the following long line in mysqld.vcproj: I have not yet encountered the line length limit in Visual Studio, but I have found the length of the directory list makes it hard sometimes to debug problems with missing/wrong libraries in the path. I have noticed that for every library you name in a TARGET_LINK_LIBRARIES command, two directory names are generated: one of them ends with the name of the library, for example ...\myisam\, and the other ends with OutDir, for example ...\myisam\$(OutDir). In my own projects, as far as I can tell, the OutDir directories never exist, so listing them effectively more than doubles the length of the list without adding any benefit. It would be helpful (at least in my case) to be able to turn off the production of the OutDir directories in this list, I just haven't gotten around to figuring out how. Is there a simple way to control this? Both directories are always added. This is hard-coded in the VS7 generator. The reason is that it is not known when the user specifies a link directory in CMake code whether that directory points directly at a library or points to another CMake build tree in which there are per-configuration subdirectories. With the information about link libraries and directories currently available from CMakeLists.txt files it is not possible to compute which path is needed. We do have plans to add a way to provide the extra information needed to compute the proper link directories exactly but this requires a few major changes and will not be done soon. My own lists of libraries tend to be bloated by the repetition of some directories (i.e. the exact same directory at different points in the string), but I think this has something to do with the fact that I am naming libraries in TARGET_LINK_LIBRARIES that are themselves built by CMake and they have their own TARGET_LINK_LIBRARIES commands. Sometimes a project depends on libraries X and Y where X also depends on Y, and I think this makes Y show up twice. But that seems like a harder problem to solve, and I don't really expect there to be a fix for it. CMake in CVS removes duplicate directories automatically. It also computes a safe order for the link directories to make sure the proper libraries are found by the linker. I've just modified the VS7 generator to use for each link directory either a relative path or a full path, whichever is shorter. This should minimize the string length. These changes will be included in the upcoming 2.4 release. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why does cmake 2.4.0 (beta) compile header files?
Phillip Hellewell wrote: Why does CMake version 2.4.0 cause VS7 to compile header files? That's really weird. I don't even understand what it means to compile a header file, but sure enough, it is doing it. I think VS7 is dumb for trying to compile a header file, but I know it never had this problem with older versions of CMake. So could it have something to do with setting ObjectFile, which was put in to fix another bug? I've always put header files in my ADD_EXECUTABLE command to get the header files to show up in a VS7 project. I don't mind taking the header files out of the ADD_EXECUTABLE command if there is some other place I am supposed to put them to get them to show up in the project. I tried adding the list of header files to a SOURCE_GROUP, but that only works if the header files are also part of the ADD_EXECUTABLE. I cannot duplicate this problem. Please post a minimal example that 1.) compiles headers with cmake 2.4.0 beta 2.) does not compile headers with cmake 2.2.3 Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How change debug target names? appd.exe libd.dll
Carlos Capdepon wrote: What I have to do to my CMakeLists.txt files to have this tree: /build /build/bin /build/lib And names of the debug and release files are equal but adding a d in the names of debug files. You can change the names, but you cannot remove the per-configuration subdirectory right now. In CVS CMake and the upcoming 2.4 release you can set the DEBUG_POSTFIX target property on the files. See the documentation of the SET_TARGET_PROPERTIES command for details, but the short-hand is SET(CMAKE_DEBUG_POSTFIX d) ADD_LIBRARY(...) ADD_EXECUTABLE(...) You can setup the install rules to install without the per-configuration subdirectory, but currently it is not possible to change this in the build tree. It may not be too hard to implement, but someone will have to investigate it. You can submit a feature request here: http://www.cmake.org/Bug Please also send me the resulting bug number. Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] request feature cmake -E tar
Xavier Delannoy wrote: hi all, it would be great to have the '-C' option example : cmake -E tar xvzf mytar.tgz -C mydestdir Feature requests may be submitted here: http://www.cmake.org/Bug For now try this: cmake -E chdir mydestdir cmake -E tar xvzf /path/to/mytar.tgz -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem for configure ITK using CMake
Lin, Lan wrote: I have a strange problem for configuring ITK using CMake. This has been done successfully before I reinstall the windows system. Today I try to do this, but there is a problem. I use CMake 2.2.3-win32, and ITK toolkit2.4.0. Here is what I do. I put ITK in the src folder, and select src folder in GUI of CMake. The binary folder is selected also. Then I choose Visual 6 as my compiler. After press configuration button, it starts to configure ITK. But the program stops at somewhere that is looking for pow. I wait for more than 5 minutes. It seems the CMake is not responding. I stop it. When I run CMake again, it stops at another place. I do not know what the problem is. I vaguely recall someone mentioning this before, but I've never been able to reproduce it. I think VS6 is getting stuck and CMake blocks waiting for it. Next time it happens bring up the task manager and look for cmake, cmakesetup, and msdev processes. Is any of them doing anything? Try killing the msdev process and see if CMake continues. Also look for the files CMakeOutput.log and CMakeError.log somewhere in your build tree (either at the top or in the CMakeFiles subdirectory). See if either log mentions something about the test on which it got stuck. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.2: builddir rpath encoded into installed binary
Michael Biebl wrote: Hi all, I got project where I create a lib (libfoo) and a binary (bar) where bar links against libfoo. If I run objdump -p bar on the uninstalled binary in $builddir/src I get RPATH=$builddir/src. If I run make install the resulting binary still has RPATH set to $builddir/src. (Note: this does not happen with cmake 2.4). As I can't enforce the usage of cmake 2.4, how can I tell cmake 2.2 to not encode the rpath into the installed binary? Set CMAKE_SKIP_RPATH to ON. Then you will get no RPATH at all. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CFLAGS and visual studio project properties
Xavier Delannoy wrote:
Hi all,
I use cmake 2.3 (KDE release).
I'm not able to force /MD in release build and /MDd in debug build. here is how I proceed:
in my CMakeLists.txt
IF(WIN32)
SET(PLATFORM_C_FLAGS /W3 /MD /O2 /Gs)
SET(PLATFORM_C_FLAGS_DEBUG /W3 /MDd /Zi /Od)
ENDIF(WIN32)
SET(CMAKE_C_FLAGS ${PLATFORM_C_FLAGS})
SET(CMAKE_C_FLAGS_RELEASE ${PLATFORM_C_FLAGS})
SET(CMAKE_C_FLAGS_DEBUG ${PLATFORM_C_FLAGS_DEBUG})
[snip]
whereas .vcproj file doesn't use my CFLAGS ;( ;(
[snip]
Optimization=2
RuntimeLibrary=0
WarningLevel=3
Is this a C or C++ project file? If it is C++ you need to use
CMAKE_CXX_FLAGS* instead of CMAKE_C_FLAGS*.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CFLAGS and visual studio project properties
Xavier Delannoy wrote: Brad King [EMAIL PROTECTED] wrote: Xavier Delannoy wrote: I use cmake 2.3 (KDE release). I'm not able to force /MD in release build and /MDd in debug build. here is how I proceed: Is this a C or C++ project file? If it is C++ you need to use CMAKE_CXX_FLAGS* instead of CMAKE_C_FLAGS*. It's a C project. What is the exact version number you are using? cmake --version I think this was fixed somewhat recently and may be okay in the 2.4.0 beta (for which you'll also need the fixed Windows-cl.cmake in the download directory). A 2.4.1 beta should be out soon too. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] behaviour of CMAKE_INCLUDE_CURRENT_DIR ?
Alexander Neundorf wrote:
Hi,
how does CMAKE_INCLUDE_CURRENT_DIR behave ?
Let's say I do
SET(CMAKE_INCLUDE_CURRENT_DIR ON)
in my toplevel src/CMakeLists.txt.
If a src/sub1/CMakeLists.txt contains
add_executable(hello main.cpp)
src/sub1/ will be part of the include path.
But what happens in the following case:
Until now there was
# apply for all subdirs
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
add_subdirectory(bar1)
add_subdirectory(bar2)
add_subdirectory(bar3)
add_subdirectory(bar4)
I guess in this case the include_directories() command has to stay ?
Yes. CMAKE_INCLUDE_CURRENT_DIR just adds a target's directory to the
include path of its source files.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode generator problems
Axel Roebel wrote: Thanks, in fact I found the problem! It is due to the repeated call of CollapseFullPath () which is used to determine the current absolute path cmDependsC.cxx for each dependency file with absolute path. This call is extremely costly on the mac. And it seems completely unnecessary because the current directory is never changed in cmDependsC.cxx. Initialization of the otherwise unused member Directory with the current directory and elemination of CollapseFullPath reduced dependency determination on the mac from 2 minutes too 8 seconds. This is even faster than for cmake 2.2.3. I have send a patch for closer inspection of the solution via the bug tracker. Thanks. I've fixed it. See this for details: http://www.cmake.org/Bug/bug.php?op=showbugid=3191 -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building executable from static libs / rpath
Christian Lang wrote:
Then link them together into an executable:
ADD_EXECUTABLE(exe ...)
TARGET_LINK_LIBRARIES(exe ${START_WHOLE_ARCHIVE} ${SOURCE_LIBS}
${END_WHOLE_ARCHIVE} ${LIBS})
where SOURCE_LIBS are the static libs built in step one and LIBS are
some shared libs. (START_WHOLE_ARCHIVE is -Wl,--whole-archive on
linux, END_WHOLE_ARCHIVE -Wl,--no-whole-archive).
It's not clear whether you are saying this works or asking how to get it
to work.
As LIBS are shared libs, the corresponding directories appear in the
rpath, which is desired. But SOURCE_LIBS are static libs, and their
directories (located somewhere in my home-direcetory) appear in the
rpath too - which is not desired. How can I avoid this?
For the executable in the build tree you have the choice of either the
current rpath or no rpath at all (set the SKIP_BUILD_RPATH property).
For the executable in the install tree you can set the rpath by setting
the INSTALL_RPATH target property on the executable. Take a look at the
documentation of SET_TARGET_PROPERTIES for details.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build/Link with static libs
Christian Lang wrote: Christian Lang wrote: Alexander Neundorf schrieb: my first problem is solved: To link against foo/libbar.a, the link line options -Lfoo -lbar are produced. This works. But what if for some reason I do not want to use it this way, but want to directly specify foo/libbar.a at the link line (as I tried in the first place)? Is this possible? You can specify the full path to libbar.a Ok, but if I specify - for instance - /path/foo/libbar.a (TARGET_LINK_LIBRARIES), cmake transforms it to -L/path/foo -lbar at the link line ... That's because on most platforms passing the full path to a static library causes the linker to copy the entire archive instead of just the objects needed. CMake splits the path into -L and -l to avoid this problem, but it also computes a safe link directory order to make sure the library is found at the location specified. It warns if no safe order exists. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack problems.
Axel Roebel wrote: I just tried the cpack program. It failed when executing a post_install_script which is configured to access the installed libraries and to rename them. Unfortunately this seems to be required if one wants to install a static and a shared library of the same name. In CMake 2.4 you can easily create a static and shared library with the same name. They just have to have different logical target names: ADD_LIBRARY(foo SHARED ...) ADD_LIBRARY(foo-static STATIC ...) SET_TARGET_PROPERTIES(foo-static PROPERTIES OUTPUT_NAME foo) Be careful when doing this on Windows though because the shared library will create a foo.lib export library which has the exact same name as the foo.lib static library. CMake makes no attempt to diagnose or resolve this conflict, so it is up to the user to be sure they are always in different directories. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: SPAM-MED: Re: SPAM-MED: RE: SPAM-MED: Re: [CMake] Error adding rule using 2.4.1 beta
Reggie Burnett wrote: I've discovered the problem. the cmakelists.txt files, as they sit on my system, have lowercase names. When I change them to mixed case (CMakeLists.txt), they work. Given that Windows is not case sensitive, this is baffling. I have had SFU installed on this system and it did prompt during install if I wanted to make a system change allowing for case sensitivity but now I can't find any info on turning that off. Any ideas? Windows filesystems are case-insensitive but CMake's internal tables that track files called CMakeLists.txt are case-sensitive. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Error adding rule using 2.4.1 beta
Reggie Burnett wrote: Brad King wrote: Reggie Burnett wrote: I've discovered the problem. the cmakelists.txt files, as they sit on my system, have lowercase names. When I change them to mixed case (CMakeLists.txt), they work. Given that Windows is not case sensitive, this is baffling. I have had SFU installed on this system and it did prompt during install if I wanted to make a system change allowing for case sensitivity but now I can't find any info on turning that off. Any ideas? Windows filesystems are case-insensitive but CMake's internal tables that track files called CMakeLists.txt are case-sensitive. Perhaps that's something that should be rethought? The files must be called CMakeLists.txt and nothing else. On case sensitive file systems it makes a big difference. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] bug or feature ? relative paths with INCLUDE_DIRECTORIES() in cmake 2.4.1
Alexander Neundorf wrote:
The following CMakeLists.txt:
include_directories( foo ${CMAKE_CURRENT_SOURCE_DIR}/bar)
add_executable(hello main.c)
produces the flags:
gcc ... -I/home/alex/src/test/bar -Ifoo
I would have expected that foo is also interpreted as relative to
CMAKE_CURRENT_SOURCE_DIR, but apparently it isn't.
Bug or feature ?
It's a bug. This is just another command that hasn't been coverted to
interpret relative paths.
Maybe if the option CMAKE_ALWAYS_INCLUDE_CURRENT_DIR is enabled, it would
also make sense to automatically add
${CMAKE_CURRENT_BINARY_DIR}/the_relative_path to the include path.
What is the_relative_path?
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] bug or feature ? relative paths with INCLUDE_DIRECTORIES() in cmake 2.4.1
Alexander Neundorf wrote:
Von: Brad King [EMAIL PROTECTED]
Alexander Neundorf wrote:
I would have expected that foo is also interpreted as relative to
CMAKE_CURRENT_SOURCE_DIR, but apparently it isn't.
Bug or feature ?
It's a bug. This is just another command that hasn't been coverted to
interpret relative paths.
This is now fixed in CVS CMake. It should be included in 2.4.3 but it
is too late for 2.4.2.
Maybe if the option CMAKE_ALWAYS_INCLUDE_CURRENT_DIR is enabled, it would also make sense to automatically add
${CMAKE_CURRENT_BINARY_DIR}/the_relative_path to the include path.
What is the_relative_path?
include_directories( bar/ )
-
would then add ${CMAKE_CURRENT_SOURCE_DIR}/bar/ and
${CMAKE_CURRENT_BINARY_DIR}/bar/
... it's just an idea, not sure it's a good one.
I don't think this is an obvious consequence of the name
CMAKE_INCLUDE_CURRENT_DIR.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] file depending on a target
Brandon J. Van Every wrote:
How can I make a file depend on a target? I have a lexer SILEX.EXE that
I generate. I need other files to depend on the existence of SILEX.EXE,
so that I can lex and create new output. It seems like
target-depends-on-target is dealt with, and file-depends-on-file, and
even target-depends-on-file. But not file-depends-on-target.
My current headscratching code:
EXE_C_TARGET(silex) # Generates silex.c from silex.scm
ADD_EXECUTABLE(silex ${Chicken_BINARY_DIR}/silex.c)
SET_TARGET_PROPERTIES(silex PROPERTIES COMPILE_FLAGS ${STATIC_FLAGS})
TARGET_LINK_LIBRARIES(silex libchicken-static)
ADD_CUSTOM_COMMAND(
OUTPUT ${Chicken_BINARY_DIR}/easyffi.l.silex
MAIN_DEPENDENCY ${Chicken_SOURCE_DIR}/easyffi.l
DEPENDS silex
COMMAND silex ${Chicken_SOURCE_DIR}/easyffi.l
${Chicken_BINARY_DIR}/easyffi.l.silex
)
ADD_FILE_DEPENDENCIES(${Chicken_BINARY_DIR}/easyffi.c
${Chicken_BINARY_DIR}/easyffi.l.silex
)
It seems that DEPENDS silex will not refer to the SILEX.EXE target.
Rather, it thinks it's an ordinary file level dependency.
That's okay. The make process that evaluates the file-level dependency
will not be executed until it is known that the exe target is up to
date. That is what the target-level dependency does.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating a shared and static library of the same name
Michael Biebl wrote: On 5/15/06, Xavier Delannoy [EMAIL PROTECTED] wrote: it's possible with CMake greater to 2.3.4. I used two diferent destination directories for the static and shared libs. Thanks Xavier for this detailed (and lengthy) instructions. But they are way too complicated and cumbersome imho. Under Unix/Linux it's not that uncommon that you want to create both, a shared and dynamic library (of the same name of course). Why not add a new keyword to add_library like BOTH so it automatically creates both types. On platforms like windows, where there are potential problems as Brad outlined, you could output a warning or create a workaround like two different output folders automatically. The interface to enable it is not an issue. Creation of two targets with one list of sources could be packaged up in a macro. The problem is supporting Windows where libraries almost never use the same name for static and shared versions. Somehow you have to always use two directories. For projects that don't care about windows using two libraries with the same name in the same directory is not a problem if one is shared and one is static. Currently the only thing preventing this is the code that removes all possible names (shared or static) for a target before linking it. This causes the targets in the same directory to clobber each other. We can add a target property to disable this. Then your code could look like this: ADD_LIBRARY(foo-shared SHARED foo1.cxx) SET_TARGET_PROPERTIES(foo-shared PROPERTIES OUTPUT_NAME foo CLEAN_DIRECT_OUTPUT 1) ADD_LIBRARY(foo-static STATIC foo1.cxx) SET_TARGET_PROPERTIES(foo-static PROPERTIES OUTPUT_NAME foo CLEAN_DIRECT_OUTPUT 1) and could easily be package in a macro. Note that the CLEAN_DIRECT_OUTPUT property does not yet exist and I made it up for this example. It tells CMake to not remove the static copy of a library when linking the shared one and vice versa (currently this is done to avoid problems when a project switches between shared and static builds). If you have a better name in mind please suggest it. Comments? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Possible bug: config_OUTPUT_NAME not used as target property LOCATION
Laurentiu Nicolae wrote:
My project requires the generation of DLLs and executables with
different postfixes for different configurations. Therefore I am setting
the config_OUTPUT_NAME accordingly. However, when I try to add a
post-build step to the build (as described in the manual), the LOCATION
property of the target is set to the original generated name, regardless
of the configuration. I can of course work around this by setting the
prefixes by hand in the post-build command, but I believe this to be a
bug. The reason being: if I am using the config_OUTPUT_NAME options,
the LOCATION property becomes rather useless, because it points to
something that may not be there any more.
Yes, this is a bug. The LOCATION property was around long before the
target properties that could affect the name on a per-configuration
basis. When those options were added the LOCATION property was never
updated to deal with them and was left alone to support existing code.
CMakeLists.txt excerpt:
SET_TARGET_PROPERTIES ( ${ProjectName} PROPERTIES DEBUG_OUTPUT_NAME
${ProjectName}D )
SET_TARGET_PROPERTIES ( ${ProjectName} PROPERTIES
RELWITHDEBINFO_OUTPUT_NAME ${ProjectName}Q )
SET_TARGET_PROPERTIES ( ${ProjectName} PROPERTIES
RELEASE_OUTPUT_NAME${ProjectName}R )
GET_TARGET_PROPERTY ( DllLocation ${ProjectName} LOCATION )
ADD_CUSTOM_COMMAND ( TARGET ${ProjectName}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy ${DllLocation} ${QOutputPath}
)
This is a known problem we've been ignoring until someone needed it
because it is a pain to address. The problem is that we need to have a
single value at CMake configure time (the LOCATION) split into multiple
values at CMake generate time (the per-configuration LOCATION).
One idea we've had is to return a special string for the LOCATION
property which is recognized by the generator and replaced with the
right thing in each generated configuration, though this leads to a
hackish special syntax behind the scenes. Another idea is to allow a
separate custom command to be specified for each configuration, though
this will lead to duplicate code and complicated loops in user code. We
have not figured out quite what to do.
Please submit a bug report here:
http://www.cmake.org/Bug
Thanks,
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and it's invocation from MS VC7
Steve Johns wrote: Is this right-click procedure available in MS VS .NET 2003, do you know? If so, I'm not clear on where to find it. Yes, it is. If you look at the Solution tab and select any target, such as ALL_BUILD, use the + to open the target. There is a CMakeLists.txt file listed. Right-clikc on that file and choose Build. When I do this, I don't see Build, but I do see Compile. Selecting Compile results in: 'Building Custom Rule DIRNAME.vcproj.cmake' I think this is what was intended, yes? (our versions must differ slightly for some reason). Yes, Compile is correct. Sorry for the confusion. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and it's invocation from MS VC7
Steve Johns wrote: CMake considers upper-case C to be a C++ extension by default because is a common convention on UNIX, and Windows is case-insensitive. Try adding the files like this: ADD_LIBRARY(NRC206 addint.c ...) Thanks for the suggestion. I tried this, but the result was still: AdditionalOptions = /TP for each file. Is there another approach? CMake converts file names it is given to be the case they are actually found on disk (for case-preserving filesystems like Windows). Rename the files on disk to be lower case also. If that is not an option there may be something else to do but I'll have to investigate. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and it's invocation from MS VC7
Steve Johns wrote:
Once it is implemented properly you could do something like
SET(NRC206_SRCS ADDINT.C ...)
SET_SOURCE_FILES_PROPERTIES(${NRC206_SRCS} PROPERTIES COMPILE_LANGUAGE C)
ADD_LIBRARY(NRC206 ${NRC206_SRCS})
to override the default choice of compile language for capital .C
extensions. I'm not sure when we'll get to this.
At this point, with the new CMake 2.4.2 successfully treating foo.c
as a C file, I have an opposite need to compile certain C files as C++.
IOW, I need to apply /TP to certain specific files like FOO.C (or
foo.c).
Can I arrange this, either with the sytax above, or some other way,
using CMake 2.4.2 ?
This would require the COMPILE_LANGUAGE property I mentioned to do
directly. We'll probably implement this soon but it is not in 2.4.2.
Can't you just rename the file to have a C++ extension? If not, you can
get foo.c compiled as C++ by creating an extra file called foo.cxx
and adding it instead. The file would contain just the code
// foo.cxx
#include foo.c
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] macro within a custom command
Brandon J. Van Every wrote:
What I really want is a simple text substitution macro, of the form:
MACRO(SIMPLE_SCM_TO_C root)
${VALID_CHICKEN} ${Chicken_SOURCE_DIR}/${root}.scm -output-file
${Chicken_BINARY_DIR}/${root}.c ${CHICKEN_FLAGS})
ENDMACRO(SIMPLE_SCM_TO_C)
[snip]
If there's no way to perform a simple text substitution on a custom
build rule's COMMAND line, then that's really really irritating. I
already had to expand out all my build rules into explicit
ADD_CUSTOM_COMMAND statements, because only DEPENDS works on
source-file-to-source-file dependencies.
Try using FOREACH:
FOREACH(root batch-driver ...)
ADD_CUSTOM_COMMAND(
OUTPUT ${Chicken_BINARY_DIR}/${root}.c
MAIN_DEPENDENCY ${root}.scm
DEPENDS parameters.scm
COMMAND ${VALID_CHICKEN} ${Chicken_SOURCE_DIR}/${root}.scm
-output-file ${Chicken_BINARY_DIR}/${root}.c ${CHICKEN_FLAGS}
)
ENDFOREACH(root)
ADD_FILE_DEPENDENCIES is useless for that purpose.
The ADD_FILE_DEPENDENCIES macro has a horrible name and was not well
documented or intentionally added to the release. It is meant only for
the deprecated OBJECT_DEPENDS target property. Please ignore its
existence. I'm going to try to get it removed completely in 2.4.3 since
it was not in the 2.2 release.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: macro within a custom command
Brandon J. Van Every wrote:
DEPLIST(chicken build chicken-ffi-macros chicken-more-macros tweaks)
SIMPLE_SCM_TO_C(chicken)
You could take advantage of variable macro arguments. The token
${ARGN} will be replaced by arguments beyond those explicitly named.
Try something like this (untested):
MACRO(SIMPLE_SCM_TO_C root)
SET(deplist ${ARGN})
ADD_SUFFIX(deplist .scm)
ADD_CUSTOM_COMMAND(
OUTPUT ${Chicken_BINARY_DIR}/${root}.c
MAIN_DEPENDENCY ${root}.scm
DEPENDS ${deplist}
COMMAND ${VALID_CHICKEN} ${Chicken_SOURCE_DIR}/${root}.scm
-output-file ${Chicken_BINARY_DIR}/${root}.c ${CHICKEN_FLAGS}
)
ENDMACRO(SIMPLE_SCM_TO_C)
SIMPLE_SCM_TO_C(chicken build chicken-ffi-macros chicken-more-macros tweaks)
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Another (minor) bug: config_OUTPUT_NAME not used for pdb and idb files
Laurentiu Nicolae wrote: Hi all, I just noticed that the postfix I use for the debug build is not used for the pdb and idb files. Namely, I get: QBase_D.dll QBase_D.exp QBase_D.ilk QBase_D.lib QBase.idb qbase.pdb I'm guessing this should be fixed in the generator. Note also that the pdb file is all lowercase (which has no impact whatsoever on a Windows platform, but I thought I should mention it anyway). Please create a bug report for this here: http://www.cmake.org/Bug Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] linux debugging flags
frederic heem wrote:
The pwlib library has recently changed its linux debug flags to -g3 -ggdb -O0,
it is believed that it makes debugging easier, is there a way to integrate it
into cmake ?
What do you mean by integrate it into cmake?
If you want to build a project with these flags just edit the
CMAKE_C_FLAGS_DEBUG and CMAKE_CXX_FLAGS_DEBUG entries to have them and
then set the CMAKE_BUILD_TYPE entry to Debug.
If you want to override the CMake default for yor project you can write
SET(CMAKE_USER_MAKE_RULES_OVERRIDE_C ${CMAKE_CURRENT_SOURCE_DIR}/User.cmake)
PROJECT(FOO C)
at the top of the project and then put the code
SET(CMAKE_C_FLAGS_DEBUG -g3 -ggdb -O0 CACHE STRING Debug options.)
in User.cmake.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating links / Uninstalling links
Michael Biebl wrote:
what's the the correct way to do the following:
1) Compile and install a binary foo to /usr/bin/foo
2) Create a link /usr/bin/bar - /usr/bin/foo
3) On make uninstall remove /usr/bin/foo and /usr/bin/bar
For 1+2, I used
SET_TARGET_PROPERTIES(foo PROPERTIES POST_INSTALL_SCRIPT make_links.cmake)
In CMake 2.4 you can do
ADD_EXECUTABLE(foo foo1.cxx ...)
INSTALL(TARGETS foo DESTINATION bin)
INSTALL(CODE
EXECUTE_PROCESS(
COMMAND \${CMAKE_COMMAND} -E remove \${CMAKE_INSTALL_PREFIX}/bin/bar
COMMAND \${CMAKE_COMMAND} -E create_symlink foo
\${CMAKE_INSTALL_PREFIX}/bin/bar
)
LIST(APPEND CMAKE_INSTALL_MANIFEST_FILES
\${CMAKE_INSTALL_PREFIX}/bin/bar)
)
The INSTALL(CODE ...) command puts code directly into the install
script. Note that by escaping the dollar signs '\$' they are placed
literally into the script which will evaluate the variables at install
time. The CMAKE_INSTALL_MANIFEST_FILES variable maintains a list of
installed files.
Use this with care...the code will still try to run on Windows platforms
where there are no symlinks and the executables have a .exe extension.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem Finding OpenGL on BSD...
Asmodehn Shade wrote: I am using Cmake to find few dependencies for some personal projects. I setup correctly the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to get all my SDL_* dependencies found and working fine. But I also in my script do a simple : FIND_PACKAGE(OpenGL) And when doing a ccmake, I get the following error : CMake Error: OPENGL_DIR is not set. It must be set to the directory containing OPENGLConfig.cmake in order to use OPENGL. And I cant find any file named OPENGLConfig.cmake... I wasnt able so far to find out where that might come from either... Any body having the same problem ? Any idea on what's wrong and how to fix it ? I am using cmake 2.4.2 from pkgsrc on NetBSD. I can remember I had a similar issue with 2.0.3... Is there a file FindOpenGL.cmake anywhere in your installation? It should be in PREFIX/share/CMake/Modules or something like that. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make in a subdir takes ages.
Thomas Zander wrote: On Friday 26 May 2006 16:28, you wrote: If you only want to build a target, then run make targetname/fast it will skip all of the depend steps, and only build that target. Doesn't seem to work here on my 2.4-p2 Try it in the top level instead of the subdir. It looks like those shortcut targets were left out of the subdirs. We'll fix it. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Thomas Zander wrote: On Friday 26 May 2006 16:24, you wrote: I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. [snip] And as I know a little about usability I know that the best way to solve the issue is to make it easier to find and type them. My first solution there would be to have to most used ones part of a new imaginary command; wmake with options like: wmake -v which ends up doing the same as 'make VERBOSE=true' but be easier to find since its visible when the user types 'wmake --help' [snip] The suggestion is to have a command, cmake in the quoted part, wmake in the suggestion above, that allows the developer to have a more usability friendly front end. CMake is a build system *generator*, not a build tool. It generates files for *native* build tools that do not come with CMake. The most common native tool on unix is...make! We have put some effort into making the Makefile interface nicer but as you said it is somewhat hopeless to make make pretty. If you do not like the command line interface provided by make then you have two choices: 1.) Use another interface such as KDevelop and the corresponding generator in CMake. 2.) Find or write your own native build tool with the command line interface of your choice and contribute a generator for it to CMake. This could be an unsermake generator for example. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
Steve Johns wrote: Excellent! Thanks very much for this info. I'm seeing a problem, though. CMake is not finding my config file, even though it does exist. CMake announces its search with forward-slash paths, but I'm in the VS C++ IDE. Is CMake not actually looking for: c:\Temp\traps.p01\trunk\TRAPS2\traps_config.txt (I guess not, or it would find it, because the file does exist there.) Is this a bug, or a driver error of some sort? Below is the CMake output from the Build - Deleting intermediate files and output files for project 'jklib2', configuration 'Debug|Win32'. Building Custom Rule c:/Temp/traps.p01/trunk/JKLIB2/CMakeLists.txt CMake Error: File c:/Temp/traps.p01/trunk/TRAPS2/traps_config.txt, does not exist. Forward-slashes are the way CMake keeps track of paths internally, and they should work fine even on Windows. What is the exact CONFIGURE_FILE call you are using? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
Steve Johns wrote:
What is the exact CONFIGURE_FILE call you are using?
Here it is, cut and pasted:
IF(CMAKE_CONFIGURATION_TYPES)
# Handle multi-configuration generators.
FOREACH(config ${CMAKE_CONFIGURATION_TYPES})
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.txt,
${CMAKE_CURRENT_BINARY_DIR}/${config}/traps_config.txt)
ENDFOREACH(config)
There was a typo in my example: it should not have the comma between the
arguments. The trailing comma is being considered part of the file name!
ELSE(CMAKE_CONFIGURATION_TYPES)
# Handle single-configuration generators.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.txt,
${CMAKE_CURRENT_BINARY_DIR}/traps_config.txt)
ENDIF(CMAKE_CONFIGURATION_TYPES)
Be careful with this. For an in-source build this may not work. That
is why my original example included a .in extension on the input file.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: XML/expat link error
Doug Henry wrote:
actually, I have found if I change the following entry (add expat to the
linker flags) in cmxmlrpc/CMakeLists.txt this problem goes away:
TARGET_LINK_LIBRARIES(xrtest cmXMLRPC cmexpat expat ${CMAKE_DL_LIBS})
From where is that other expat library coming? I bet the build of
cmXMLRPC is accidentally using system expat headers instead of cmexpat
headers. The include directory order in Utilities/cmxmlrpc may need
fixing. In that directory's CMakeLists.txt file change the lines
INCLUDE_DIRECTORIES(
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_EXPAT_INCLUDES}
${CMAKE_CURL_INCLUDES}
)
to
INCLUDE_DIRECTORIES(BEFORE
${CMAKE_CURL_INCLUDES}
${CMAKE_EXPAT_INCLUDES}
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
)
and try bootstrapping again with a fresh tree.
-Brad
On 5/26/06, *Doug Henry* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I receive the errors below when building versions 2.2.3 and 2.4.2.
It looks like the cmexpat library is not linking in when cmXMLRPC
library is used. I have ./Utilities/cmexpat/libcmexpat.a so it did
build, not sure what would cause this.
[TOOLS cmake-2.4.2]$ make
Linking C executable ../../bin/xrtest
/mnt/tools/RPM/TMP/cmake-2.4.2/Utilities/cmxmlrpc/libcmXMLRPC.a(xmlrpc_expat.o):
In function `xml_parse':
xmlrpc_expat.c:(.text+0x848): undefined reference to `XML_ParserCreate'
xmlrpc_expat.c:(.text+0x862): undefined reference to `XML_SetUserData'
xmlrpc_expat.c:(.text+0x87c): undefined reference to
`XML_SetElementHandler'
xmlrpc_expat.c:(.text+0x88d): undefined reference to
`XML_SetCharacterDataHandler'
xmlrpc_expat.c:(.text+0x8a6): undefined reference to `XML_Parse'
xmlrpc_expat.c:(.text+0x8d8): undefined reference to `XML_ParserFree'
xmlrpc_expat.c:(.text+0x947): undefined reference to `XML_GetErrorCode'
xmlrpc_expat.c:(.text+0x94f): undefined reference to `XML_ErrorString'
xmlrpc_expat.c:(.text+0x96c): undefined reference to `XML_GetErrorCode'
xmlrpc_expat.c:(.text+0x974): undefined reference to `XML_ErrorString'
collect2: ld returned 1 exit status
make[2]: *** [bin/xrtest] Error 1
make[1]: *** [Utilities/cmxmlrpc/CMakeFiles/xrtest.dir/all] Error 2
___
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] Building a library with fortran and c code
Doug Henry wrote: Has there been any resolution to this issue? I receive a variety of mod.proxy errors when compiling fortran using cmake 2.4.2. No one has had time to investigate the problem. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a Release Version in MSVC6
Ben Larson wrote: Is the correct way to tell MSVC6 to build a release version of my project to use the command SET (CMAKE_BUILD_TYPE Release) in the CMakeLists.txt file? No. CMAKE_BUILD_TYPE is used to select the configuration for single-configuration generators such as Makefiles. The VS6 generator is a multi-configuration generator, so CMAKE_BUILD_TYPE is ignored and both Debug and Release configurations are generated. When you load the project in the IDE go to the Build menu and select Set Active Configuration. In the resulting dialog set the configuration to ALL_BUILD - Win32 Release and then build the project. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Assembler files
James Mansion wrote:
I'd like to create a library from a mix of
assembler and C files.
I'm reading the book to try to determine how
to achieve this. There seems to be perhaps two
possible approaches.
(Initially this is for Win32, and I have files for NASM
and MASM with extensions .nasm and .masm)
1) define new languages for NASM and MASM.
The example in the book (Fortran) suggests that I then need to
enable the language in the PROJECT declaration, though the
section on PROJECT suggests that all languages are enabled
by default. (?) Presumably I'm safe if I use ENABLE_LANGUAGE?
Then I would just use ADD_LIBRARY (foo a.c b.nasm c.masm).
Is that right?
This is mostly right, but currently there is no NASM or MASM language.
You have to look at all the *Fortran*.cmake files in the Modules
directory. Create similar ones for NASM and MASM in some directory in
your project, say myproj/CMake. Then in myproj/CMakeLists.txt do
SET(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/CMake)
PROJECT(MYPROJ C NASM MASM)
Note the above is from memory so it may need some tweaking.
2) Define a whole set of custom commands that create an object
file:
SET( MASM_SOURCES b1.masm b2.masm )
FOREACH( SRC ${MASM_SOURCES} )
ADD_CUSTOM_COMMAND(TARGET obj for ${SRC}
PRE_LINK
COMMAND masm ${SRC}
)
ENDFOREACH( SRC )
ADD_LIBRARY( foo a.c b1.obj b2.obj )
Is that right?
Try something like
SET(MASM_NAMES b1 b2)
FOREACH(src ${MASM_NAMES})
SET(MASM_SRC ${CMAKE_CURRENT_SOURCE_DIR}/${src}.masm)
SET(MASM_OBJ ${CMAKE_CURRENT_BINARY_DIR}/${src}.obj)
ADD_CUSTOM_COMMAND(
OUTPUT ${MASM_OBJ}
DEPENDS ${MASM_SRC}
COMMAND masm ${MASM_SRC} -o${MASM_OBJ}
)
SET(MASM_OBJECTS ${MASM_OBJECTS} ${MASM_OBJ})
ENDFOREACH(src)
ADD_LIBRARY(foo a.c ${MASM_OBJECTS})
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] libs only target
Jan Woetzel wrote: is there a way to compile/link only the libs (ADD_LIBRARY) but skip linking the executables (ADD_EXECUTABLE) using a global option/switch on cmake level? I want to save compilation time when I need only the libraries for linking my client project. But we have about 200 examples in subdirectories and linking them takes a lot of time... OPTION(BUILD_EXAMPLES Build examples OFF) IF(BUILD_EXAMPLES) ADD_SUBDIRECTORY(Examples) ENDIF(BUILD_EXAMPLES) -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ccmake . configure changes intel compiler selection from icc back to gcc! Why? Anyone know?
Dan White wrote: Hi all, Doing an OSX VTK build on intel core duo platform OSX10.4 Cmake 2.4 patch2 VTK CVS yesterday trying to use intel compilers for OSX intel ccmake . configure changes intel compiler selection from icc back to gcc! Why? Anyone know? also it changes icpc back to g++ icc and icpc are both installed and seem to work from the command line in the terminal ok. Why should ccmake . chose to ignore my compiler selection and change them back to the gnu/apple compilers? An older version of cmake didnt seem to do this yesterday, but i figured i should use the newest version Once a compiler has been selected for a particular build tree it cannot be changed. If you did an in-source build you will have to get a fresh checkout. If you did an out-of-source build you will need a new build tree. Then run CC=icc CXX=icpc ccmake /path/to/VTK -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make in a subdir takes ages.
Thomas Zander wrote: btw; does that include a /fast on install? Good idea. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.4.2 Cygwin shouldn't have -ldl
Brandon J. Van Every wrote:
I have investigated, and I'm not convinced that the -ldl is coming from
my code. My code is:
CHECK_INCLUDE_FILE(dl.h HAVE_DL_H)
IF(HAVE_DL_H)
ADD_DEFINITIONS(-DHAVE_DL_H)
SET(EXTRA_LIBS ${EXTRA_LIBS} ldl)
ENDIF(HAVE_DL_H)
There is no dl.h on any hard drive of my system. Which is to be
expected, as it's a Linux thing. I think the -ldl more likely from
building CMake 2.4.2 on Cygwin incorrectly. I will await your canonical
version and see if the problem goes away.
What does HAVE_DL_H say in your cache? If you remove the entry manually
from the file does it come back with yes?
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.4.2 Cygwin shouldn't have -ldl
Brandon J. Van Every wrote:
Brad King wrote:
Brandon J. Van Every wrote:
I have investigated, and I'm not convinced that the -ldl is coming
from my code. My code is:
CHECK_INCLUDE_FILE(dl.h HAVE_DL_H)
IF(HAVE_DL_H)
ADD_DEFINITIONS(-DHAVE_DL_H)
SET(EXTRA_LIBS ${EXTRA_LIBS} ldl)
ENDIF(HAVE_DL_H)
There is no dl.h on any hard drive of my system. Which is to be
expected, as it's a Linux thing. I think the -ldl more likely from
building CMake 2.4.2 on Cygwin incorrectly. I will await your
canonical version and see if the problem goes away.
What does HAVE_DL_H say in your cache?
//Have include dl.h
HAVE_DL_H:INTERNAL=
If you remove the entry manually from the file does it come back with
yes?
When I run ccmake again, it comes back with exactly the same thing.
To be very sure of the conclusion, I comment out the entire
CHECK_INCLUDE_FILE sequence.
Now there is no way for my code to be inserting a -ldl. It still shows up.
Linking C shared library libchicken.dll
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
cannot find
-ldl
collect2: ld returned 1 exit status
make[2]: *** [libchicken.dll] Error 1
make[1]: *** [CMakeFiles/libchicken.dir/all] Error 2
make: *** [all] Error 2
I'm inclined to believe that the CMake 2.4.2 build on Cygwin has an
error in it somewhere.
Go to your build tree for CMake and run bin/ctest to make sure all the
tests pass. They definately build some shared libraries.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] handling global state
Brandon J. Van Every wrote: I need some stylistic advice on handling global state. I'm starting to break my monolithic CMakeLists.txt up into subdirectories. I'm building the Chicken compiler and I need to do staged builds. A lot of essentially the same operations, done on itself multiple times so that it's compiled up to its own most current version. I realize I can use the cache to pass global state. Before CMake 2.4 the only way to get information from subdirectories was to set it as INTERNAL cache variables and then configure again. Now you can get variable settings from subdirectories using GET_DIRECTORY_PROPERTY. However it looks like you want to pass information from the top-level down, which is trivial. However, there's often global state that I don't want the user to modify. Nor do I really want to clutter the output of CMakeSetup with such extraneous state. I could mark those variables as advanced, which reduces the immediately visible clutter, but I don't really want clutter in the advanced variables either. Also they can still modify them, which is not what I want. For instance I've got certain constants like the minimum Chicken build number, and nothing good can come from someone changing them. I've also got a lot of -D flags from probing the system, that go into ADD_DEFINITIONS. I don't want the user to mess with 'em, or run the probes multiple times. I just want to determine them at the toplevel and then pass them down to subdirectories. I could include constants via an INCLUDE(global.cmake) file, but I'd rather have them in the toplevel CMakeLists.txt. Right at the beginning of it, where a maintainer can easily see what's going on and nothing is obfuscated. So how do you pass read-only global state to subdirectory consumers? There is no such thing as a read only variable setting except by convention. If you set a variable in the top level then all subdirectories will get that value. However, if one subdirectory changes it the other children will not see the altered value. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] handling global state
Brandon J. Van Every wrote: I suppose CACHE INTERNAL docstring is for if I want to pass values back up from the subdirectories, or across subdirectories? See GET_DIRECTORY_PROPERTY to get variables from subdirs. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] libs only target
Jan Woetzel wrote: Brad King wrote: IF(BUILD_EXAMPLES) Thanks Brad, that's almost the approach we currently use except IF (BUILD_EXAMPLES OR BUILD_TESTING) for ctest ADD_TEST executable targets. However, we are not satisfied with this approach because: (1) If someone has built only the libs and he decides he wants the examples, he has to run cmake to set BUILD_EXAMPLES (which takes time) which creates/configures a new config.h (from config.in). This config.h is included alomost everywhere and thus everything is unneccessarily rebuilt. Why do you have a definition for BUILD_EXAMPLES in the top-level config.h? Building the libs certainly shouldn't care whether examples will be built. If a few of the sources do need to know for some reason just create a different configured header for BUILD_EXAMPLES and include it in only the sources that need it. So we prefer the approach of target: - all build libs+executables, - libs compiles+links all libraries but skips compiling+linking executables. ADD_CUSTOM_TARGET(libs) ADD_DEPENDENCIES(libs lib1 lib2) -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 3rd party cmake files
Alexander Neundorf wrote:
Ok, we need a solution here.
Now that cmake is going to enter the center stage :-) things are going to
change in this regard.
Until now cmake comes with FindFoo.cmake modules for all other software packages.
Once other software packages will also use cmake as their native buildsystem it will be better if these projects deliver the required cmake files themselves, be it FindFoo.cmake or FooConfig.cmake files.
In KDE we have now already two independent software packages:
kdewin32 and qtdbus, which both use cmake as their native build system, which
are both independent from KDE and which both have to be installed before
starting to compile KDE (i.e. kdelibs).
Now in kdelibs we need a way to find kdewin32 and qtdbus.
For kdewin32 this wouldn't be a big problem. For qtdbus there are more issues.
It features some cmake macros for code generation (QTDBUS_ADD_INTERFACES()).
These are used when building qtdbus itself and also when compiling software
which uses qtdbus. So qtdbus should install the cmake files which contain these
macros.
Requiring every user to manually adjust KDEWIN32_Dir and QTDBUS_Dir is not
really an option for the long term.
What's wrong with using FIND_PATH to locate FooConfig.cmake as I
suggested previously? Then kdelibs would have a FindFoo.cmake that
contains no knowledge of Foo except that it provides a FooConfig.cmake.
Project Foo would install FooConfig.cmake to contain all the
information about where Foo is located. The CMake code in kdelibs would
have
FIND_PACKAGE(Foo)
which uses the kdelibs copy of the simple FindFoo.cmake. If it is not
found automatically for some reason then the user would set Foo_DIR to
the location of one file (rather than Foo_INCLUDE_DIR and Foo_LIBRARY
separately).
In this solution FindFoo.cmake contains only a few lines like
find_path(QtDBUS_DIR FindQtDBUS.cmake PATHS ...)
if(EXISTS ${QtDBUS_DIR}/QtDBUSConfig.cmake)
include(${QtDBUS_DIR}/QtDBUSConfig.cmake)
else(EXISTS ${QtDBUS_DIR}/QtDBUSConfig.cmake)
# ...report not found...
endif(EXISTS ${QtDBUS_DIR}/QtDBUSConfig.cmake)
which does not depend on the Foo version and thus does not have to come
with Foo. Since the find_path command can list PATH_SUFFIXES and other
places to look, kdelibs should be able to find Foo automatically.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.2 CMAKE_CXX_FLAGS_DEBUG
frederic heem wrote: It has been suggested to use the following command to set different debug compiler flags: SET(CMAKE_CXX_FLAGS_DEBUG -g3 -ggdb -O0 CACHE STRING Debug options.) Unfortunately, it no longer works with cmake 2.4.2. It is ignored, only -g is present. Did this work in any version of CMake? Try this: SET(CMAKE_CXX_FLAGS_DEBUG -g3 -ggdb -O0 CACHE STRING Debug options. FORCE ) Read the documentation of the SET command for details. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 3rd party cmake files
Alexander Neundorf wrote:
In this solution FindFoo.cmake contains only a few lines like
find_path(QtDBUS_DIR FindQtDBUS.cmake PATHS ...)
if(EXISTS ${QtDBUS_DIR}/QtDBUSConfig.cmake)
include(${QtDBUS_DIR}/QtDBUSConfig.cmake)
else(EXISTS ${QtDBUS_DIR}/QtDBUSConfig.cmake)
# ...report not found...
endif(EXISTS ${QtDBUS_DIR}/QtDBUSConfig.cmake)
which does not depend on the Foo version and thus does not have to come
with Foo. Since the find_path command can list PATH_SUFFIXES and other
places to look, kdelibs should be able to find Foo automatically.
Ok, will try that.
Still I have a slightly bad feeling with the FooConfig.cmake approach, since
this hardcodes the locations, whereas a normal FindFoo.cmake feels more
flexible.
There is no reason FooConfig.cmake has to hard code paths. It is
generated by the author of project Foo. It can use paths relative to
Foo_DIR.
Where should I install the file to, something like
CMAKE_INSTALL_PREFIX/share/qtdbus/cmake/ ?
That looks fine to me. The small FindQtDBUS file has to know where to
look for it though.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] another RPATH problem
Alexander Neundorf wrote: Hi, although cmake now supports RPATH very flexible, we still have a problem. The install RPATH has to be constructed manually. In KDE we set it to the Qt libdir, the KDE libdir and the install libdir. Now the problem is, what to do if the app links to a library which has been found (e.g. /usr/lib/dbus/lib/libdbus-1.so ) but which isn't in the LD_LIBRARY_PATH ? Requiring every developer to adjust the INSTALL_RPATH manually for every lib he links to doesn't seem like a viable solution. Another option is just to require that (DY)LD_LIBRARY_PATH is set up correctly. But I see a third option which sounds quite compelling to me. When linking and when relinking during install, cmake adds all required link dirs using -L ... to the command line. Shouldn't it be possible to use the same set of link dirs also for the RPATH ? This would solve all our problems I think. It will be hard to separate build-tree linking dirs from install-tree linking dirs. Consider a pair of projects A and B. I build A, and then build B using the build tree of A to link its libraries. Then I install both. Now B's rpath will point at the build tree of A instead of its install location. Every project will have its own policy of RPATH/no-rpath/etc. I think the best solution is to have the Find*.cmake scripts provide a FOO_RUNTIME_LIBRARY_DIR variable along with FOO_LIBRARY and FOO_INCLUDE_DIR. This directory could then be used for the RPATH of something that links to FOO. Also on Windows it would provide the location of foo.dll which may be different from that of the foo.lib being linked. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cannot get moc to run on win32 in subdirectories
Patrick Noffke wrote:
I'm using cmake 2.4.2 on windows, with Visual Studio 2005 Express Edition.
I have a Qt class in a subdirectory from my top-level project. I don't want to
build the class as a library, but rather include the source code in the
top-level project. But I can't get moc to run on the file in the subdirectory.
A snippet of my CMakeLists.txt looks like this:
SET(FIXED_ASPECT_IMAGE_DIR
${my_project_SOURCE_DIR}/src/fixed_aspect_image_win32)
GET_FILENAME_COMPONENT(infile ${FIXED_ASPECT_IMAGE_DIR}/FixedAspectImage.h
ABSOLUTE)
MESSAGE(STATUS infile = ${infile})
MESSAGE(STATUS moc = ${QT_MOC_EXECUTABLE})
IF (EXISTS ${infile})
MESSAGE(STATUS infile exists)
ENDIF (EXISTS ${infile})
ADD_CUSTOM_COMMAND(OUTPUT ${FIXED_ASPECT_IMAGE_DIR}/FixedAspectImage.moc
COMMAND ${QT_MOC_EXECUTABLE}
ARGS ${moc_includes} -o ${FIXED_ASPECT_IMAGE_DIR}/FixedAspectImage.moc
${infile}
DEPENDS ${infile})
ADD_FILE_DEPENDENCIES(${infile} ${FIXED_ASPECT_IMAGE_DIR}/FixedAspectImage.moc)
The project is my_project, and the above CMakeLists.txt is in the src subdirectory.
The FixedAspectImage class is in the fixed_aspect_image_win32 directory (below the src directory).
I've tried QT4_AUTOMOC, but this puts the moc file in the src subdirectory, not in
fixed_aspect_image_win32 (this causes the #include FixedAspectImage.moc line to not
find the .moc file).
I tried QT4_GENERATE_MOC, but no rule to generate the moc file was getting created. So I
copied the ADD_CUSTOM_COMMAND from QT4_GENERATE_MOC, and this still doesn't generate the
rule. I'm getting the infile exists status message, and the moc executable
is pointing to the right place. I can run the moc command from the command line just
fine.
Other source files in the src directory are getting moc rules (using
QT4_AUTOMOC for those), and moc is in fact run for them.
Why can't I get the moc to run on a file in a subdirectory? Or how can I get
the QT4_AUTOMOC to output the file in the same place as the header file?
Incidentally, I'm not able to build Qt applications out of the source tree, and it's the
same sort of problem. The moc files are generated in the build directory, causing the
#include foo.moc lines to not find the .moc files.
In addition, I can get this to work on Linux just fine with the
QT4_GENERATE_MOC command.
Custom command outputs created by ADD_CUSTOM_COMMAND may be referenced
only in the directory containing the command but not subdirectories.
You should use the INCLUDE_DIRECTORIES command to add the location of
the moc file to your include path. Alternatively set the
CMAKE_INCLUDE_CURRENT_DIR variable to 1.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Incorrect code generated in DSP project file for IDL source file -- HELP!
Bennett Smith wrote: Hello, I am trying to use cmake for building a project on Windows. This project is currently built using Visual Studio 6.0, and it uses the ATL libraries to produce some COM components. Part of this is the invocation of the MIDL compiler to process a file with the .IDL extension. When I add this file to the list of sources in the CMakeLists.txt file it seems to produce an incorrect section in the generated DSP file. Here is what I want/expect: SOURCE=.\Echo.idl # ADD MTL /tlb .\Echo.tlb /h Echo.h /iid Echo_i.c /Oicf # End Source File # Begin Source File Here is what I actually get: SOURCE=D:\CMAKE_PRACTICE\SRC\Echo\Echo.idl !IF $(CFG) == Echo - Win32 Release # ADD CPP /tlb !ELSEIF $(CFG) == Echo - Win32 Debug # ADD CPP /tlb !ELSEIF $(CFG) == Echo - Win32 MinSizeRel # ADD CPP /tlb !ELSEIF $(CFG) == Echo - Win32 RelWithDebInfo # ADD CPP /tlb !ENDIF Could someone please teach me the secret hand-shake to get cmake to generate a DSP file with correct entries for MIDL invocation? I don't think CMake knows how to do that. The VS6 generator is not as well-maintained as the others. You can submit a feature request here: http://www.cmake.org/Bug but I don't know when there will be time to implement it. If you want to try to patch CMake yourself look at Source/cmLocalVisualStudio6Generator.cxx to get started. Just include the patch in the feature request if you get it working. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about INSTALL_TARGETS error
[EMAIL PROTECTED] wrote:
hi, all
I am using GUISupport/Qt come with the vtk5.0 and try to compile with
cmake but get the following error message:
CMake Error: Error in cmake code at
/home/me/vtk/VTK/GUISupport/Qt/CMakeLists.txt:183:
INSTALL_TARGETS called with incorrect number of arguments
[snip]
INSTALL_TARGETS( ${VTK_INSTALL_LIB_DIR} QVTK ) # !!! Line 183, error
here!!!
The variable is supposed to contain the install destination. If it does
not then you are probably not building all of VTK. You need to build
VTK using the top level source directory.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Error: Attempt at a recursive or nested TRY_COMPILE in directory
Bernd Schubert wrote:
Hello Alex, hello Brad,
thanks a lot for your help.
You are trying to put the build tree of the try-compile test on top of
the main build tree. Try this:
Ah, I begin to understand.
TRY_COMPILE(C_MAKE_COMPILER_WORKS
${CMAKE_BINARY_DIR}/CMakeTmp
${PROJECT_SOURCE_DIR}/CMake_Modules/Test_64_Bit_Offset.c
OUTPUT_VARIABLE_OUTPUT)
However, you may want to look at the CheckCSourceCompiles module.
I already switched to this module and it works fine.
So the example in the book is slightly wrong. Is this already fixed in the new
version (for CMake-2.2)? Or to whom should I send a report.
I'll check to make sure this is fixed.
Thanks,
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] g++ -frepo and cmake
Manuel Klimek wrote:
Hi,
i'm trying to use cmake with g++ to build template using code
with -frepo for shared libraries.
With -frepo g++ automatically includes the object code only for
template instantiations that are needed at link time. If
you link an executable with g++, say
g++ -frepo -o hello hello.o main.o
and hello.cc uses templates, g++ will insert missing template
instantiations into hello.o until the executable links.
Now this doesn't work for shared libraries:
g++ -frepo -shared -o libhello.so hello.o
will simply compile without adding the extra template instantions
into hello.o.
The gcc mailing list suggests the following solution:
First compile a dummy 'closure' executable, which fails:
g++ -frepo -o libhello_closure hello.cc
(fails complaining about missing symbols)
Afterwards, hello.o contains all the required symbols.
Then
g++ -frepo -shared -o libhello.so hello.o
will yield a library with all symbols as expected.
At the moment I implement this solution using a wrapper
script around g++, which simply looks for -shared, and in
case of -shared first performs the closure step and than
compiles the whole executable.
Because an additional shell indirection slows down my
build process, I wondered if I can integrate the -frepo
concept into my cmake process.
I tried:
- using ADD_EXECUTABLE (with a simple closure.cpp containing a main(...)):
fails, because in linux symbols are only required at executable
link time, not at library link time
- using ADD_CUSTOM_COMMAND:
I don't know how to get the command line cmake would use to create
a library, so I can't write a custom command - and because g++ would
return an error code, the build wouldn't work anyways, would it?
So the question is: do you think using a wrapper script is the
only way, or did I miss something and I can do it with cmake?
Look at the current setting of CMAKE_CXX_CREATE_SHARED_LIBRARY:
MESSAGE(CMAKE_CXX_CREATE_SHARED_LIBRARY =
[${CMAKE_CXX_CREATE_SHARED_LIBRARY}])
This is the variable CMake uses to construct the link rule for the
shared library. You could try adding your wrapper shell script to it:
SET(CMAKE_CXX_CREATE_SHARED_LIBRARY
/path/to/wrapper/script ${CMAKE_CXX_CREATE_SHARED_LIBRARY})
Then your script would be called only for linking instead of for every
object file built.
Otherwise you could get some improvement by replacing your wrapper
script with a small C program that would load faster than a shell script
and then exec g++.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] another RPATH problem
Alexander Neundorf wrote: Attached you can find a patch against current cvs which adds an option with the nice name CMAKE_USE_EXTERNAL_RPATH_FOR_INSTALL, which if enabled has the effect that lib dirs which are outside the build- and source tree are added to the install RPATH. Okay, I've implemented it as a target property called INSTALL_RPATH_USE_LINK_PATH that is initialized from the variable CMAKE_INSTALL_RPATH_USE_LINK_PATH. It causes the linker search path directories not in the project to be appended to the INSTALL_RPATH when the target is built for installation. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target_link_libraries doubt
Vikas Kumar wrote: I understand that it is currently not possible. But take the case where you as a software product developer, are given a proprietary .dll/.so file and you are creating a library that links with that file. If ld -o foo.so -static bar.so foo.o , can be written in a makefile and made to work, why cannot cmake have such an option ? Look at the value of the variables CMAKE_C_CREATE_SHARED_LIBRARY and CMAKE_CXX_CREATE_SHARED_LIBRARY. You can set it yourself to change the rule. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MACRO arguments
Filipe Sousa wrote:
The fallowing code is making me crazy. I can't understand why the output is
always FALSE
MACRO(FOO1 x)
IF(x)
This is the same as writing
IF(x)
outside the macro.
MACRO(FOO2 x)
IF(${x})
This is the same as writing
IF(hello)
outside the macro.
MACRO(FOO3 x)
IF(${x})
This is the same as writing
IF(hello)
outside the macro.
Macro arguments are replaed by doing a string replacement of ${x} with
the value of the argument. They are NOT variables, which is why these
are called macros and not procedures or functions. You can convert
macro arguments to variables using the SET command:
MACRO(FOO4 x)
SET(X ${x})
IF(X)
MESSAGE(TRUE)
ELSE(X)
MESSAGE(FALSE)
ENDIF(X)
ENDMACRO(FOO4)
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] another RPATH problem
Alexander Neundorf wrote: Would it be possible to apply it also to the 2.4 branch, but maybe keep it undocumented until it has proven its usefulness ? I can test it on my machine, but it can get wider testing (KDE) only if it goes into the 2.4 branch. We'll merge it to the 2.4 branch for the 2.4.3 release. You can just test if from the CVS version because currently there has been no new development that won't be put on 2.4. Is it actually possible to query the cmake patch level from within cmake files ? The last time I tried it didn't work. From the second run on one can use CMAKE_CACHE_RELEASE_VERSION, but this is empty on the first run. It is now in CVS and it will be in 2.4.3, and if CMAKE_PATCH_VERSION is not set you can assume an earlier version. If this would be possible I could adjust the RPATH handling depending on the cmake version without requiring everybody to update his cmake. If you set the target property for the new feature but the CMake version is 2.4.2 nothing will happen because it ignores unknown properties. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and install_name_tool on the Mac
Karl Merkley wrote: Does CPack have any ability to help with the install_name_tool on the Mac? Mac applications avoid DLL hell by creating an application bundle that is really a directory structure that includes the application, the resources, and the shared libraries used by the application. My understanding is that the install_name_tool essentially modifies the RPATH of the distributed application so that it looks for the shared libraries in the bundle rather than some random location. I have a script that I run to make this all work, but it has to be modified as libraries change. Or, if I somehow forget to run this step the whole distribution is bad. Does CPack help with this? Look at the SET_TARGET_PROPERTIES command documentation: cmake --help-command SET_TARGET_PROPERTIES In CMake 2.4 there is an INSTALL_NAME_DIR property that you can use to control the install_name of the installed library or executable. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and install_name_tool on the Mac
Karl Merkley wrote: On Jun 16, 2006, at 11:47 AM, Brad King wrote: Karl Merkley wrote: Does CPack have any ability to help with the install_name_tool on the Mac? Mac applications avoid DLL hell by creating an application bundle that is really a directory structure that includes the application, the resources, and the shared libraries used by the application. My understanding is that the install_name_tool essentially modifies the RPATH of the distributed application so that it looks for the shared libraries in the bundle rather than some random location. I have a script that I run to make this all work, but it has to be modified as libraries change. Or, if I somehow forget to run this step the whole distribution is bad. Does CPack help with this? In CMake 2.4 there is an INSTALL_NAME_DIR property that you can use to control the install_name of the installed library or executable. So this is actually part of the make install process then, right? Yes, but it can be made to happen at build time too if you do not care about running from the build tree (the BUILD_WITH_INSTALL_RPATH property). Are there any examples anywhere? I'd even be willing to write it up in the wiki ;-) If you get it working a Wiki entry would be great. Here is an example to get you started (from memory): ADD_LIBRARY(mylib SHARED ...) SET_TARGET_PROPERTIES(mylib PROPERTIES INSTALL_NAME_DIR @executable_path/../lib ) ADD_EXECUTABLE(myexe ...) TARGET_LINK_LIBRARIES(myexe mylib) INSTALL(TARGETS mylib DESTINATION lib) INSTALL(TARGETS myexe DESTINATION bin) You'll have to modify this example to be bundle-specific. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake_*_compile_flags doubt
Vikas Kumar wrote: Hi Is there a way that I can change compile flags based on the target I am building. I have played around with all the cmake command options given and I am kinda out of ideas. So it seems that the CmakeCache.txt variables are my only hope. But I do not have enough knowledge nor do I have the CMake book to help me. (apparently it is out of stock) As an example of the case that I have, in one directory I have some source files. These source files need to be built and linked and archived into static libraries. But the catch here is that they all use #ifdef's. Since the code is supposed to be high-performance oriented, we cannot afford to use runtime if-then-else checks. Hence compile time checks are done. All the code is in C. Now there are only 2 constants that are used in the code, lets call them DEF_CON_1 and DEF_CON_2. Let the source files be src1.c and src2.c . Both these source files use the above constants and compile different functions based on the constants and are supposed to create two different target static libraries, libfoo1. a and libfoo2.a . Now all of this is done under one Project. I want to do PROJ(Test) ADD_LIBRARY(foo1 STATIC src1.c src2.c) ADD_LIBRARY(foo2 STATIC src1.c src2.c) using ADD_DEFINITIONS() sets the defines for all the targets. using SET_SOURCE_FILES_PROPERTIES() sets the COMPILE_FLAGS for the sources for whatever targets they are used to build. SET_TARGET_PROPERTIES() does not work for static libraries, otherwise I could have used target_EXPORTS instead. Now is there a way that I can set CMAKE_C_COMPILE_FLAGS type variables for the same sources pertaining to different targets. Use SET_TARGET_PROPERTIES to set the COMPILE_FLAGS property. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.2 vs cmake 2.2.3
Vikas Kumar wrote:
Hi
There is a difference in the way these two versions handle the
installation part.
Here is the snippet from the cmake_install.cmake file generated with
cmake-2.4.2.
IF(NOT DEFINED CMAKE_INSTALL_PREFIX)
SET(CMAKE_INSTALL_PREFIX /home/vikas/installer/)
ENDIF(NOT DEFINED CMAKE_INSTALL_PREFIX)
STRING(REGEX REPLACE /$ CMAKE_INSTALL_PREFIX
${CMAKE_INSTALL_PREFIX})
Why is the REGEX part replacing the last '/' character ? It is
automatically generated by Cmake, so how do I prevent cmake from
generating it ?
This results in creation of directories named installerbin,
installerlib instead of installer/bin and installer/lib. The above
code worked fine in cmake-2.2.3
The install prefix should never have been set with a trailing slash.
Your install rules should use leading slashes if you are using
INSTALL_TARGETS, INSTALL_FILES, or INSTALL_PROGRAMS. If you switch to
using the INSTALL command in 2.4.2 (not compatible with 2.2 though),
then you do not need a leading slash.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compaq Fortran 6.1 detection fails under Windows
Philippe Poilbarbe wrote: Hello, I am trying to compile fortran code under Windows. When the Fortran language is enabled, the fortran checking routine shows the following error: Determining if the Fortran compiler works failed with the following output: nmake -f CMakeFiles\cmTryCompileExec.dir/build.make /nologo -L CMakeFiles\cmTryCompileExec.dir\build Building Fortran object CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.obj C:\PROGRA~1\MICROS~2\DF98\BIN\F90.EXE -o CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.obj -c C:\devel\BRAT\CMakeFiles\CMakeTmp\testFortranCompiler.f F90: error: Switch '-o' is ambiguous NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~2\DF98\BIN\F90.EXE' : return code '0x1' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio\VC98\BIN\nmake.exe' : return code '0x2' Stop. Did somebody have the same kind of problem and solved it ? The fortran compiler if Compaq Fortran 6.1 and it does not seem to have a -o option (f90 -help command output is below). CMake version: 2.4.2 That compiler is not known to CMake. You'll have to set the variable CMAKE_Fortran_COMPILE_OBJECT to teach CMake how to use the compiler. Look at the Modules/Platform/Windows-ifort.cmake file in the CMake installation for an example. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding Boost for Windows and Linux.
Andrew Maclean wrote:
Bill, If you think it is generally OK and useful to people, tell me what
improvements are needed before it would be eligible for inclusion in the
modules directory of CMake.
This will definately be a useful contribution.
I have had a go at writing a FindBoost.cmake file (attached). It tries
to find where the boost includes are using educated guesses and then
tries to determine the path to the library files. The problem with
windows is that there is no default library path.
Is there a better way of doing this for both windows and linux? I have
searched the web but most examples are just for linux and only seem to
do part of the job.
Does Boost suggest that any environment variables be set for its
location? Does it set any registry entries on Windows?
The rationale for my solution is outlined below.
I think my solution is a bit rough around the edges but pointing in the
right direction. For example:
If I have a path like /usr/local/include/boost-1_33_1/boost
How can I get the /usr/local part so I can append /lib to it?
Using GET_FILENAME_COMPONENT is fine, but you may not need to strip as
much as you are now.
The problem is that I could have a paths like:
/user/local/include/boost
/user/include/boost-1_33_1/boost
/user/local/include/boost
C:\boost\include\boost
C:\boost\include\boost\boost-1_33_1\boost
My problem is that I want to set up a BOOST_INCLUDE_PATH (easy, just
look for a file like config.hpp).
The hard part is determining the library path it is either:
${BOOST_INCLUDE_PATH}/../../../lib
or
${BOOST_INCLUDE_PATH}/../../lib
What determines during boost installation which of these paths is used?
I'm guessing it is whether the version number was included in the
install directory..
You can see from the attached code that I used a series of IF ( EXISTS ...
Is this the best way to do this?
# Usage:
# In your CMakeLists.txt file do something like this:
# ...
# # Boost
# INCLUDE(FindBoost.cmake)
This should be
FIND_PACKAGE(Boost)
The module should also pay attention to the variable
Boost_FIND_REQUIRED. If it is set and boost is not found it should exit
with a MESSAGE(FATAL_ERROR ...). The variable is set by the
FIND_PACKAGE command when it loads the module if it is called like this:
FIND_PACKAGE(Boost REQUIRED)
For finding the include path, look at the PATH_SUFFIXES option of the
FIND_PATH command. You should be able to find the headers like this:
FIND_PATH(BOOST_INCLUDE_DIR
NAMES boost/config.hpp
PATH_SUFFIXES boost-1_33_1 ...)
Then you will not need to strip the boost/ part of the path, and the
sub-path boost-1_33_1 will be searched underneath every other search
path specified. Then you can use code like
IF(${BOOST_INCLUDE_DIR} MATCHES boost-[0-9]+_[0-9]+)
to test how many levels need to be stripped to find the PREFIX/lib
directory.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking static libraries into shared libs?
Daniel Sands wrote:
I have some static libraries and need to link them into my CMAKE
project's shared libraries. Is there a platform-independent way to
specify this? What I want can be expressed by the following:
g++ -shared -o libmylib.so my_obj_files.o -Wl,-whole-archive
-lmy_static_lib -Wl,-no-whole-archive
On SGI:
cc -shared -o libmylib.so my_obj_files.o -Wl,-all -lmy_static_lib
-Wl,-notall
CMake has no table mapping to these flags automatically, but if you set
them up yourself CMake will not change them. Any link library option
beginning with a - is left untouched, so you can do something like
SET(MYLIB my_static_lib)
IF(${CMAKE_SYSTEM} MATCHES IRIX)
SET(MYLIB -Wl,-all -lmy_static_lib -Wl,-notall)
ENDIF(${CMAKE_SYSTEM} MATCHES IRIX)
#...
TARGET_LINK_LIBRARIES(my_shared_lib ${MYLIB})
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.2 vs cmake 2.2.3
Vikas Kumar wrote: I agree. But even though I do not set the install prefix with a trailing /, the leading slash becomes necessary. That REGEX expression is generated anyway, and the fault is not with the REGEX expression. The fault is with the fact that I need to add a leading slash if i use a cmakelists.txt file from cmake-2.2.3 and am using INSTALL_TARGETS(). So INSTALL_FILES() and INSTALL_TARGETS() is not exactly backward compatible in cmake-2.4.2 in the way it works for cmake-2.2.3. I consider the change a bug fix. Previously if CMakeLists.txt authors followed the leading slash convention and the user added a trailing slash to the install prefix then a double-slash would be present which was causing some other problems. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_PACKAGE REQUIRED - concept chnage?
Jan Woetzel wrote: Jan Woetzel wrote: The REQUIRED flag checking in FIND_PACKAGE(Foo REQUIRED) is not checking the result of FOO_FOUND anymore. [snip] In 2.0.6 each find script just had to set _FOUND and the FIND_PACKAGE command was handling teh rest automatically. I cannot find any code that would have done this in CMake 2.0. What makes you think this worked? (2) The documentation is only in Modules/readme.txt but missing in the FIND:_PACKAGE commadn help. The part about _FIND_REQUIRED and _FIND_QUIETLY is useful only to module authors so it is in the readme. Someone using FIND_PACKAGE to find a package does not care. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking and CMakelists.txt
Steve Johns wrote: Hi. I have a project that links to an external library that I've build successfully (in MSVC 7.1) using LINK_LIBRARIES()andLINK_DIRECTORIES() in my CMakelists.txt file. When I delete one or both of these directives, the project still builds! I don't see how it can, without the info on how to find the library. Then, if I futz around enough with it (imprecise term, I know), eventually the project will cease to build. Then, if I futz some more, restoring LINK_LIBRARIES()and LINK_DIRECTORIES() it will build again (eventually). I was under the impression that edits to the CMakelists.txt file were detected by CMake, which would then start over and act in accord with the current definitions (or lack of) in the CMakelists.txt file. It is clear that my understanding requires correction or qualification, and I'd be much obliged if anyone can surmise what's occurring here and clue me in. The changes are processed by CMake immediately and the project files are regenerated. However, VS 7.1 does not seem to reliably reload the new project files always. Try exiting VS and running CMake by hand and then reloading the project in VS after editing a file. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Relation between .vcproj and .vcproj.cmake
Steve Johns wrote: I'm wondering, could someone kindly explain the relationship between the .vcproj and .vcproj.cmake files (in the MSVC build environment)? I understand that the .vcproj is the actual project file as used by the MSVC IDE, but what is the purpose of the .vcproj.cmake file (which I notice is created, generally, with a later timestamp)? BTW, comparing these two files, they are the same in the directory I'm looking at. Is this always the case? The .cmake version is an implementation detail of getting VS to re-run CMake at the proper time to regenerate projects. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake MacOSX Question
Hans J. Johnson wrote: Cmake Experts, I am running into a problem with static libraries and conflicting frameworks on MacOSX. I need to statically build my own version of tcl and tk with X11 bindings and link it to my application. The problem is that the linker is preferring to bind to the Tcl.framework and Tk.Framework dynamic libraries instead of the ones that I specify. - Notice the explicitly specified link directories - [hjohnson]$ /usr/bin/c++-bind_at_load -O2 -ftemplate-depth-50 -no-cpp-precomp -Wno-long-double -ftemplate-depth-50 -no-cpp-precomp -Wno-long-double -DNO_ITK_TCL -O3 -DNDEBUG -headerpad_max_install_names -fPICCMakeFiles/brains2.dir/tkAppInit.o CMakeFiles/brains2.dir/tkInstallCommands.o -o ../bin/brains2 -L/scratch/hjohnson/src/brains2/MacOSX/FAST/src/lib/InsightToolkit -L. -L/scratch/hjohnson/src/brains2/MacOSX/FAST/src/lib -L/usr/X11R6/lib -L/sw/lib -lb2Utils -liplGUI -lb2Utils -liplKernel -lITKBasicFilters -lITKIO -lITKNrrdIO -litkgdcm -litkjpeg12 -litkjpeg16 -litkopenjpeg -litkpng -litktiff -litkjpeg8 -lITKSpatialObject -lITKNumerics -lITKMetaIO -lITKDICOMParser -lITKEXPAT -lITKniftiio -lITKznz -litkzlib -lqHull -liplAlgorithms -liplObject -lgts -liplHeader -liplPixelTable -liplUtils -liplLogging -lITKCommon -litkvnl_inst -litkvnl_algo -litkvnl -litknetlib -litkvcl -litksys -lpthread -lm -lgts -lglib -lgmodule -lgthread -ltcl8.4 -ltk8.4 -lforms -lformsGL -lm -lX11 -lXext -lXmu -lXpm -lGLU -lGL Add the -v option to the command line to see exactly what GCC is running underneath. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] new FindwxWidgets.cmake + UsewxWidgets.cmake
Jan Woetzel wrote: Miguel A. Figueroa-Villanueva and I rewrote the find script for wxWidgets (formerly known as wxWindows). The work is based on Jorgen Boddes FindwxWin. Great, thanks. Please submit the files in a feature request on the bug tracker: http://www.cmake.org/Bug Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake MacOSX Question
William A. Hoffman wrote: At 11:09 PM 6/24/2006, Hans Johnson wrote: Thanks for all your suggestions. They put me onto the correct path to figuring out what was going on. Close inspection of the man page for ld on MacOSX indicates why the strange behavior was occuring. -search_paths_first By default when the -dynamic flag is in effect, the -lx and -weak-lx options first search for a file of the form `libx.dylib' in each directory in the library search path, then a file of the form `libx.a' is searched for in the library search paths. This option changes it so that in each path `libx.dylib' is searched for then `libx.a' before the next path in the library search path is searched. This sounds very familiar. I think we figured it out once before, and talked about making this flag the default on OSX. Does that sound like a good idea? It looks good to me. This will be consistent with what cmOrderLinkDirectories computes. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problems detecting a required version of a library
Scott Amort wrote: Hello, I am in the process of converting my C++ library project from autotools to CMake. So far, things are working very well. However, I have come across a strange problem. I have written a cmake module that attempts to detect if ANTLR is installed, by checking antlr-config (this is all done on Linux, btw). I'm using EXECUTE_PROCESS to call `antlr-config --libs', which outputs a value that I can add to TARGET_LINK_LIBRARIES What is the output value of antlr-config --libs? What is the command you are using to store the value in the cache? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] targets and dependencies
David Somers wrote: For a cmake project, it it possible to get a list of all its targets; and for the targets to get their dependencies? There is no official interface for this. You could try using get_cmake_property to get the CACHE_VARIABLES property. Look for variables of the form foo_LIB_DEPENDS. This is not guaranteed to remain the same in the future though. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problems detecting a required version of a library
Scott Amort wrote:
Hi Brad,
Thanks for the quick response.
Brad King wrote:
What is the output value of antlr-config --libs? What is the command
you are using to store the value in the cache?
The output value is: /usr/lib64/libantlr.a on my AMD64 gentoo box. I'm
not doing anything specific re: cache, here are the exact commands:
FIND_PROGRAM(ANTLR_CONFIG
antlr-config
/usr/bin
/usr/local/bin
)
IF(ANTLR_CONFIG)
EXECUTE_PROCESS(COMMAND ${ANTLR_CONFIG} --libs OUTPUT_VARIABLE
ANTLR_CONFIG_LIBS)
ENDIF(ANTLR_CONFIG)
...and later in a subdirectory's CMakeLists.txt,
TARGET_LINK_LIBRARIES(mylibrary ${ANTLR_CONFIG_LIBS})
If I output ANTLR_CONFIG_LIBS to a status message, it seems to throw an
end-of-line character into the output, which seems to be confusing the
cache used by TARGET_LINK_LIBRARIES. It is the TARGET_LINK_LIBRARIES
that causes the actual problem, if I comment it out, everything works fine.
The actual error comes after a successful `cmake .', followed by `make':
CMake Error: Parse error in cache file (...)CMakeCache.txt. Offending
entry: ;
Here are the offending lines in CMakeCache.txt:
//Dependencies for the target
mylibrary_LIB_DEPENDS:STATIC=/usr/lib64/libantlr.a
;
I'm guessing the ; separator shouldn't be on a newline.
As a bit of experimentation, I discovered that by replacing the
EXECUTE_PROCESS with:
EXEC_PROGRAM(${ANTLR_CONFIG} ARGS --libs OUTPUT_VARIABLE ANTLR_CONFIG_LIBS)
The problem is fixed. No end-of-line appears in ANTLR_CONFIG_LIBS (or
CMakeCache.txt), and the TARGET_LINK_LIBRARIES works just fine.
Perhaps a bug?
No, EXEC_PROGRAM and EXECUTE_PROCESS have different policies for
capturing the output of a program. It looks like EXEC_PROGRAM
automatically strips leading and trailing whitespace from the output,
while EXECUTE_PROCESS gives you the real output of the program.
Try putting this after EXECUTE_PROCESS:
STRING(REGEX REPLACE [\r\n]+$ ANTLR_CONFIG_LIBS ${ANTLR_CONFIG_LIBS})
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compile/install on HPUX on ia64 (Itanium)
David Akdikmen wrote:
Success with latest from CVS!!! Both make and make install seems to
work, Thanks,
Great.
I added the option by setting the environment variables before running
configure.
(At the bash prompt before running configure)
export CFLAGS=+p
export CXXFLAGS=+p
What was the original output in the log file that told you that this
option is needed? Can you compile the source
-- t1.c -
int main() { return 0; }
-
with just
cc +p t1.c
using the C compiler? What about the C++ compiler (rename to t1.cxx)?
BTW: I had to delete the whole directory in order to run configure
again, otherwise it would pick up the old results.
Actually you just had to remove CMakeCache.txt where the results are stored.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Regex changes between cmake 2.0.6 and 2.4.2 ??
Kris Dekeyser wrote:
Hi,
I was running my build macros in the latest CMake (2.4.2) and encountered very strange errors. With some debug printing I discovered that the new CMake version behaves differently regarding RegEx testing compared to the version 2.0.6 that we currently use.
This is a summary of what we do:
SET(RegexAbsoluteDir ^([a-zA-Z][:])?[/])
#--- Make directories absolute
SET(DirList)
PRINT_MESSAGE(9 WordList ${WordList})
FOREACH(word ${WordList})
PRINT_MESSAGE(9 word ${word})
IF(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 word ${word} matches ${RegexAbsoluteDir})
SET(DirList ${DirList} ${word})
ELSE(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 word ${word} does not match ${RegexAbsoluteDir})
SET(DirList ${DirList} ${${ProjectName}_SOURCE_DIR}/${word})
ENDIF(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 DirList ${DirList})
ENDFOREACH(word)
With Cmake 2.4.2 I got this output:
-- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include does not
match ^([a-zA-Z][:])?[/\]
-- DirList
D:/Workspace/EDA/1.1/Packages/EDA_Interface/D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
With Cmake 2.0.6 I got:
-- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include matches
^([a-zA-Z][:])?[/\]
-- DirList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
I just ran your example with 2.4.2 and got the latter output.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] subdirectories INSTALL(FILES subdir/foo.h ...)
Jan Woetzel wrote: Hi, I expected INSTALL(FILES subdir/foo.h DESTINATION include ) to install foo.h into include/subdir but it installs into: include Thus the subdirectory structure is lost. (1) This is a bug or am I missing something ? It works if I put the approppritae DESTINATION into each subdirectories CMakeLists.txt it works. But I want to use a globbing expression to install all headers keeping their subdirectory structure to avoid forgetting to ad dthem. I'm using Cmake 2.4.2 on Windows (with MSVS 7.1 generator). This is the expected behavior. The FILES option is meant to list the exact files that should be installed to the given destination regardless of source location. You can probably do what you want in CMake code with a combination of FILE(GLOB) and IF(IS_DIRECTORY). What is missing is an INSTALL(DIRECTORY ...) option. There is a feature request already in the bug tracker for this but it has not yet been implemented. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExceptionHandling in VC8
Laurentiu Nicolae wrote: Hello CMake users, I have noticed that the ExceptionHandling flag is not fully handled for VC8 projects. Namely, in VC7 this option could only be set to TRUE or FALSE. In VC8, we have the following options: Enable C++ exceptions : No - ExceptionHandling=0 Yes (/EHsc) - ExceptionHandling=1 Yes with SEH Exceptions (/EHa) - ExceptionHandling=2 The /EHa option is not handled by the generator and ends up in the AdditionalOptions line. This results for us in a warning (/EHsc replaced with /EHa) for every file we compile in our projects. It would be nice to have this option fully supported by CMake, especially since VC8 seems to become the new IDE of choice for Windows C++ development. There is a table in the generator used to map command line options to GUI settings in the generated project files. The /EHa option is missing from this table. You can submit a bug report here: http://www.cmake.org/Bug -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
David Somers wrote:
On Friday 30 June 2006 19:07, William A. Hoffman wrote:
At 12:26 PM 6/30/2006, David Somers wrote:
BTW, one hiccup I still have is this: for the COMMENT, how can I get it to
print out the $ character?
\$ should work.
That's what I would have expected too... but it doesn't :-(
I'm doing this from within a MACRO ... so perhaps there is something else I
need to do?
The COMMENT is placed directly in the makefile as
@echo COMMENT
In order to get make to echo a dollar you need this:
@echo \$$
Try this:
SET(COMMENT_DOLLAR \\$$)
ADD_CUSTOM_COMMAND(
...
COMMENT Here is a dollar: ${COMMENT_DOLLAR} !!!
)
Other generators will also put the comment literally in the build file,
and may require different escaping, so you may need to set
COMMENT_DOLLAR differently in those cases.
Really it should be CMake's job to figure out how to get the comment to
display as the user specified. You can submit a bug report here:
http://www.cmake.org/Bug
but it may not get attention for a while as this is pretty obscure IMHO.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Regex changes between cmake 2.0.6 and 2.4.2 ??
Kris Dekeyser wrote: I just ran your example with 2.4.2 and got the latter output. Then, is there any configuration setting that could influence the regex behavior ? No. Did you build CMake 2.4.2 yourself or use a pre-compiled binary? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_PACKAGE generator mismatch?
Amitha Perera wrote: In the VXL project, we use FIND_PACKAGE to allow internal code to use the public VXL code. As currently set up, this causes a call to CMAKE_IMPORT_BUILD_SETTINGS, which in turn checks that the internal project uses the same generator, compiler, and compiler flags as the external project. In general, I don't see why they *have* to be the same. I understand the issues with Windows and needing to make sure certain flags are matched. However, I think CMake should not force such a match. Similarly, I don't see how the choice of generator should affect the build process. Are we (VXL folks) using an outdated mechanism for build setting import? The generators do not really have to be the same, but at the time that stuff was first implemented it was far easier to require this than to check all the things necessary for binary compatibility. You could just change VXL to not do any automatic build setting import or checking. The import build settings call is not automatic in FIND_PACKAGE. The UseVXL.cmake file has it hard-coded. It could be surrounded in an if block: IF(NOT VXL_NO_IMPORT_BUILD_SETTINGS) ... ENDIF(NOT VXL_NO_IMPORT_BUILD_SETTINGS) or just removed completely and replaced by trusting user competence. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Regex changes between cmake 2.0.6 and 2.4.2 ??
Kris Dekeyser wrote:
I'm pretty sure something changed in the the interpretation of variables. I
attached a simple CMakeLists.txt file that shows the difference along with a
configuration file to read in.
Yes, this did change, but the original behavior was not intended or
documented. Note the documentation of the FILE(READ) option from 2.0:
READ will read the content of a file and store it into the variable.
This says nothing about replacing variables. The change was a bug fix.
In Cmake 2.0.6 it runs fine. In Cmake 2.4.2 it fails when reading the
configuration file. The backslashes in the last line need to be escaped. Also,
in the first line the ${...} string is not replace with the variable's
contents. That's what causes the test to fail.
Note that the CMakeLists.txt program copies each word in ${line} into a
WordList variable. It's pretty useless in the test program, but in our
configuration it actually filters out some important keywords. If I skip that
step in the test program, the test fails with Cmake 2.0.6, so I asume that the
variable interpretation was done in that step in the older Cmake.
Is there a way in Cmake 2.0.4 to force the interpretation of variables in
strings?
STRING(CONFIGURE ...)
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Per-target compiler flags?
Remi Denis-Courmont wrote: Hello, I am trying to port a project to CMake, but I couldn't find anyway to specify C preprocessor defines on a per-target (or alternatively, per-source) basis. The project is compiling the same source files multiple times with different defines, resulting in different object code... But it seems like ADD_DEFINITIONS won't support this case. SET_TARGET_PROPERTIES(mytarget PROPERTIES COMPILE_FLAGS -DMY_TARGET_DEF) -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] canonical way to distinguish CMake builds?
Brandon J. Van Every wrote: I have put ADD_DEFINITIONS(-DCMAKE_BUILD) in CMakeLists.txt and statements such as #if !defined(CMAKE_BUILD) in my .h files. Is there a canonical definition for this? I didn't see any canonical flag being passed to the C compiler, so I'm guessing there isn't one, but I have a vague memory of reading about such a thing in the archives. Couldn't find any reference to it though. No. Adding the definition yourself is the right way. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] question about linker flags from PKGCONFIG
Andriy Rysin wrote:
Hi
I've got a question about PKGCONFIG usage
Let's say I've got SOMELIB_CFLAGS and SOMELIB_LD_FLAGS from PKGCONFIG by
this:
PKGCONFIG(somelib SOMELIB_INCLUDE_DIR SOMELIB_LINK_DIR SOMELIB_LD_FLAGS
SOMELIB_CFLAGS)
I could use
SET(CMAKE_CXX_FLAGS ${SOMELIB_CFLAGS} ${CMAKE_CXX_FLAGS})
to set includes for that dir
Alternatively you can use the STRING command to extract the directories
from the -I options and then use INCLUDE_DIRECTORIES. This would allow
those include directories to be included in dependency scanning.
but I could not find any CMAKE_LD_FLAGS to
add SOMELIB_LD_FLAGS to, so that I've got my library included on linking
stage
CMAKE_C_LINK_FLAGS
CMAKE_CXX_LINK_FLAGS
or use SET_TARGET_PROPERTIES to set a LINK_FLAGS property on a specific
target.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug #3218 - Automatic Visual Studio dependency generation
Manuel Klimek wrote: Hi there, Here's a got a completely reworked version of my patch. For me this is a killer feature when working with Visual Studio 2005 and cmake: It automatically generates workspaces for projects in subdirectories that contain all required visual studio projects to compile the project in the subdirectory. This is very useful for big projects where you have many applications using a lot of common libraries, but you don't want to use the toplevel workspace, because loading time and intellisense can be a real pain. Feedback welcome :-) If you have not done so already please attach this to the bug report directly. Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and VC-80 configurations
Alex Makarenko wrote:
High all,
I'm struggling with build configurations in VC-80. I have two specific
questions:
1) Does ${OutDir} get resolved for arbitrary paths (other than to targets)?
E.g. I want to specify the path to a text config file generated during the
build. The cmake command and the result of running the test are shown below.
Notice that the path to the test executable is properly resolved but the
path to the config file is not.
# cmake:
ADD_TEST( T1010 appproptest --Config=${CMAKE_CFG_INTDIR}/apppropteston.cfg )
The tests are run by ctest which does not expand VS vars like OutDir.
Try this:
ADD_TEST( T1010 appproptest
--Config=\${CTEST_CONFIGURATION_TYPE}/apppropteston.cfg )
Note the backslash. This should put ${CTEST_CONFIGURATION_TYPE}
literally into the test file. CTest will expand this with the current
configuration (-C option) when running tests.
2) Is it possible to force VC-80 to switch configurations from cmake/ctest?
My understanding that CMAKE_BUILD_TYPE is irrelevant in this case, right? So
I try to use -C option with ctest, with no apparent result (notice /build
Release in both cases). Is there something else that needs to be done?
CMAKE_BUILD_TYPE is for the Makefile generators, so it is irrelevant
here. The -C option was originally meant for running tests but not
building. I see no reason that it should not work for driving build
too. Please submit a feature request:
http://www.cmake.org/Bug
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fortran bug? Use statement problems
Daniel Sands wrote: I'm not a Fortran programmer, but I have some code to compile into my program. It came up with false dependencies when I tried to compile it in the CMAKE framework though. The problem is traced to comment lines such as C use cross product of vectors ... Should a 'use' statement be considered a statement even on a comment line? No, this is a known bug that we haven't had time to fix. Just change the comment to not have use. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to add capability to generate preprocessed and not-yet-compiled files ?
Alexander Neundorf wrote: Hi, it would be nice if it would be possible to have for each object file also a target which only preprocesses the file and one which preprocesses and compiles, but not assembles the file (so that you get the assembler code). Is there a way to do this with macros ? I almost think this would have to be done in cmake itself. Probably somewhere where the object rules are created additionally for each object the same rule but with -E instead of -c would have to be created. It wouldn't be required to be executed on all, just on direct invocation: make foo.o/pre make foo.o/as What do you think about this ? Would you accept a patch ? Look in Modules/CMakeCInformation.cmake for the variable CMAKE_C_COMPILE_OBJECT. Other modules in the Platform directory set it also. Just duplicate the variable with one called CMAKE_C_PREPROCESS_OBJECT and then setup cmLocalUnixMakefileGenerator3.cxx to create rules with .E extensions instead of .o. You should be able to locate places that lookup *_COMPILE_OBJECT vars. See Modules/CMakeCXXInformation.cmake for the C++ version. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to add capability to generate preprocessed and not-yet-compiled files ?
John Ellson wrote: Brad King wrote: Alexander Neundorf wrote: Hi, it would be nice if it would be possible to have for each object file also a target which only preprocesses the file and one which preprocesses and compiles, but not assembles the file (so that you get the assembler code). Is there a way to do this with macros ? I almost think this would have to be done in cmake itself. Probably somewhere where the object rules are created additionally for each object the same rule but with -E instead of -c would have to be created. It wouldn't be required to be executed on all, just on direct invocation: make foo.o/pre make foo.o/as What do you think about this ? Would you accept a patch ? Look in Modules/CMakeCInformation.cmake for the variable CMAKE_C_COMPILE_OBJECT. Other modules in the Platform directory set it also. Just duplicate the variable with one called CMAKE_C_PREPROCESS_OBJECT and then setup cmLocalUnixMakefileGenerator3.cxx to create rules with .E extensions instead of .o. You should be able to locate places that lookup *_COMPILE_OBJECT vars. See Modules/CMakeCXXInformation.cmake for the C++ version. Not sure that I'm following the converstation properly here, but can any of this be used to provide access to a set of .o for use as a convenience library ? No, these variables are used to specify rules for the generators to put in the build files. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to create SOURCE_GROUP for include files
Steve Johns wrote: Hi. What I would like to accomplish: In the MS VC7.1 .Net IDE In the Solution Explorer, inside my project's folder, at the same level as the 'Source Files' folder, I would like to create a 2nd folder 'Include Files' that would contain/display the .hpp files for my project. My source tree is just a simple setup with './src' and './incl' directories containing the .cpp and .hpp files respectively. __ I must be misunderstanding something fundamental about the SOURCE_GROUP() command, or what is necessary for it to work, because despite trying every variation of: SOURCE_FILES( Include Files FILES afile.hpp bfile.hpp ) that I can conceive of typing, absolutely nothing happens, and no 'Include Files' appears in the IDE. This just assigns a group to the source files, but they still have to be explicitly added to the source list of a target. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Convenience libraries
John Ellson wrote:
how do I reference a symbol defined
in CMakeLists.txt in another directory for a list of source files?
e.g. in lib/graph/CMakeLists.txt I have:
SET(graph_SRCS attribs.c agxbuf.c edge.c graph.c
graphio.c lexer.c node.c parser.c refstr.c trie.c
)
and I want to expand this in lib/gvc/CMakeLists.txt
As long as lib/gvc is processed after lib/graph:
GET_DIRECTORY_PROPERTY(
graph_SRCS
DIRECTORY ${PROJECT_SOURCE_DIR}/lib/graph
DEFINITION graph_SRCS
)
However you will have to reference the sources by their full path so
that they can be found in the other directory.
You could also create lib/graph/sources.cmake with this code:
SET(graph_SRCS
${PROJECT_SOURCE_DIR}/lib/graph/attribs.c
${PROJECT_SOURCE_DIR}/lib/graph/agxbuf.c
...)
and then INCLUDE it in both CMakeLists.txt files.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to create SOURCE_GROUP for include files
Steve Johns wrote: ProjDir src incl lib into which directory's CMakelists.txt file should I put the SOURCE_FILES( Include Files FILES x.hpp y.hpp ) command, and could this: ADD_LIBRARY( MyLibProj x.cpp y.cpp x.hpp y.hpp ) The source and header files will not magically be found in other directories. You have to tell CMake where to find them. Try this in the top-level CMakeLists.txt file: ADD_LIBRARY(mylib src/x.cpp incl/x.hpp) SOURCE_GROUP(Include Files FILES incl/x.hpp) Basically source files have to be named with a relative path to the location of the CMakeLists.txt file. This may also work from lib/CMakeLists.txt: ADD_LIBRARY(mylib ../src/x.cpp ../incl/x.hpp) SOURCE_GROUP(Include Files FILES ../incl/x.hpp) -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Add a compiler switch to a a specific configuration
Sagnes, Frederic wrote:
Hello,
I'm using the STLport library on several targets on my project, and need to
define the _STLP_DEBUG flag on the debug configuration of each target. I looked
at :
SET_TARGET_PROPERTIES ( PROPERTIES COMPILE_FLAGS -D_STLP_DEBUG )
... but it doesn't seem to be able to specify a switch for a specific
configuration, neither can :
ADD_DEFINITIONS ( -D_STLP_DEBUG )
I hope there is a function that can do that, or a foreach trick.
Set the CMAKE_CXX_FLAGS_DEBUG variable:
SET(CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} -D_STLP_DEBUG)
or just put
#if !defined(NDEBUG) !defined(_STLP_DEBUG)
# define _STLP_DEBUG
#endif
in a top-level header that is included before all STL headers.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
