Re: [CMake] Install component with RPM package generator
2009/9/20 João Henrique Freitas joa...@gmail.com: Hi, I and some guys are trying to implement the componentization install in CPackRPM. We need some help. Any developer can guide us? Some discus exists here: http://public.kitware.com/Bug/view.php?id=7645 I'm part of that effort, the current main trouble is CPack generic generator currently assumes that a componentized installer is a **SINGLE** file which may looks good for NSIS or PackageMaker but certainly awkward for RPM, DEB or even ZIP, DEB etc... We may want to produce 1 installer file per component. We do [need to] propose some modification of the cmCPackGenerator base class and want to have CMake dev team opinion/advice on that. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compiling arm-elf on Windows host
Alexander Neundorf wrote: On Sunday 20 September 2009, Harald Kipp wrote: Alexander Neundorf wrote: On Sunday 20 September 2009, Harald Kipp wrote: add_library(nutfs STATIC basename dirent dirname) I would recommend to use the full filename, i.e. including the suffix. So probably basename.c etc. Oops, I temporarily removed the extensions after finding make target extensions like .c.o. Scanning dependencies of target nutfs [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj Das System kann den angegebenen Pfad nicht finden. Try VERBOSE=1 make to see the full command which is executed. I'll try to do this tommorrow. As expected, make fails at the cd command using slashes instead of backslashes: [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj cd C:/ethernut-4.9.6/nutbld/fs C:/Programme/yagarto/bin/arm-elf-gcc.exe-o CMakeFiles/nutfs.dir/basename.c.obj -c C:/ethernut-4.9.6/nut/fs/basename.c Das System kann den angegebenen Pfad nicht finden. (English: The system cannot find the specified path) make[2]: *** [fs/CMakeFiles/nutfs.dir/basename.c.obj] Error 1 make[2]: Leaving directory `C:/ethernut-4.9.6/nutbld' make[1]: *** [fs/CMakeFiles/nutfs.dir/all] Error 2 make[1]: Leaving directory `C:/ethernut-4.9.6/nutbld' make: *** [all] Error 2 You might try the nmake makefiles in case you have nmake. I'll try this as well. Unfortunately no luck. The generated Makefiles cannot be processed by GNU make, because nmake partly uses a different syntax, like !IF $(OS) == Windows_NT NULL= !ELSE NULL=nul !ENDIF Furthermore it adds the /nologo command line option when calling $(MAKE), which is rejected by GNU make. One reason for looking at CMake as an alternative to GNU autotools is, that we do not want to force Windows users to install Cygwin or force OS X users to install fink. It'd be great if CMake can help here. Should do. Sigh. Right now I do not see the light at the end of the tunnel. May be I should explain my goal in more detail. Our package exists of the RTOS source code, which may be build for different targets (AVR, ARM, AVR32). Furthermore it contains the source code of the Configurator tool, which creates several C header files and Makefiles based on a target board config file. Running these makefiles will create the RTOS for this specific target board. Btw. the Configurator is based on the wxWidgets version of the eCos configtool, but we replaced tcl by Lua. On Linux and OS X we use GNU autotools to create the Configurator executable. On Windows there is no such capability and the average user must stick with the pre-build executable. Then the Configurator must be executed manually to create the header and Makefile files. Finally make will create the target binaries. These steps are equal on all host platforms. We could have used autotools to create the target binaries as well, but not on Windows without installing a *nix environment. The idea is to use CMake to automatically to 1. build the Configurator tool binary, checking the compiler available, wxWidgets version etc. 2. run the Configurator for a specified target board, creating the C headers and possibly one or more .cmake files for building the target binaries 3. build the RTOS and sample applications, checking the cross compiler, target run time library etc. Thanks again for your time, Harald ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.4 won't find boost 1.40 on windows
2009/9/21 Philip Lowman phi...@yhbt.com: Thankfully, the changes made to library naming in 1.40 do not break FindBoost. :) Philip, does this apply to the latest release (i.e. cmake 2.6.4)? Or rather the latest revision in CVS? (See also below) Could you post what you have in mind for the paths? Also, bear in mind that Boost already encodes versions into the include directory and libraries. It isn't necessary to segment a boost install prefix by version number at all. Ok, so now I have installed Boost 1.40.0 with the following command: ...\boost_1_40_0.\bjam --prefix=C:\Programme\boost --build-type=complete install (i.e. without version number in the prefix). Without any additional help (for instance setting BOOST_ROOT) except set(Boost_ADDITIONAL_VERSIONS 1.40 1.40.0), FindBoost emits: Boost not in cache _boost_TEST_VERSIONS = 1.40;1.40.0;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 Boost_USE_MULTITHREADED = TRUE Boost_USE_STATIC_LIBS = Declared as CMake or Environmental Variables: BOOST_ROOT = BOOST_INCLUDEDIR = BOOST_LIBRARYDIR = _boost_TEST_VERSIONS = 1.40;1.40.0;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 Include debugging info: _boost_INCLUDE_SEARCH_DIRS = C:/boost/include;C:/boost;C:\Programme/boost;/sw/local/include _boost_PATH_SUFFIXES = boost-1_40;boost_1_40;boost-1_40_0;boost_1_40_0;boost-1_38_0;boost_1_38_0;boost-1_38;boost_1_38;boost-1_37_0;boost_1_37_0;boost-1_37;boost_1_37;boost-1_36_1;boost_1_36_1;boost-1_36_0;boost_1_36_0;boost-1_36;boost_1_36;boost-1_35_1;boost_1_35_1;boost-1_35_0;boost_1_35_0;boost-1_35;boost_1_35;boost-1_34_1;boost_1_34_1;boost-1_34_0;boost_1_34_0;boost-1_34;boost_1_34;boost-1_33_1;boost_1_33_1;boost-1_33_0;boost_1_33_0;boost-1_33;boost_1_33 guessed _boost_COMPILER = -vc90 _boost_MULTITHREADED = -mt _boost_STATIC_TAG = _boost_ABI_TAG = gd _boost_LIBRARIES_SEARCH_DIRS = C:/boost/lib;C:/boost;C:\Programme/boost/boost___/lib;C:\Programme/boost;/sw/local/lib [...] Note that something similar to the actual BOOST_ROOT is in _boost_INCLUDE_SEARCH_DIRS. Maybe the backslash in C:\Programme/boost is wrong? Ultimately we can add anything to the search path of FindBoost that makes sense. If you have suggestions, please feel free to submit them (preferably with a tested patch) to the bugtracker. I'd propose to make FindBoost recursively searching the _boost_INCLUDE_SEARCH_DIRS for the requested version. But maybe FindBoost already does that and my problems just result from that strange backslash... Kind regards Ingolf ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to set CPACK_PACKAGE_VERSION from a gengetopt configuration file
Hello, I use gengetopt to generate command line parser for my application. The configuration file *.ggo also specifies programs version like this: # Name of your program package hwtest # don't use package if you're using automake # Version of your program version 1.2.1 # don't use version if you're using automake I'd like to automatically extract these version numbers and assign them to CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH What were the best solution for my problem? Thank you in advance. Best regards, Yegor ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated FindThreads.cmake in tracker
On Sun, 2009-09-20 at 19:32 -0400, Philip Lowman wrote:
On Sun, Sep 20, 2009 at 3:02 PM, Hendrik Sattler
p...@hendrik-sattler.de wrote:
Am Sonntag 20 September 2009 17:16:19 schrieb Philip Lowman:
Hello,
I've merged (optional) Pthreads-win32 support into a
FindThreads.cmake
attached in the tracker and added some documentation on how
to use it.
Since FindThreads isn't my module I wanted to throw this up
on the mailing
list for feedback.
http://www.cmake.org/Bug/view.php?id=6399
Also, in regard to a previous mailing list thread about
FindThreads...
I'm not sure which platform the block Check if compiler
accepts -pthread
is executed on. The documentation I attached to the code
advises calling
target_link_libraries(target ${CMAKE_THREAD_LIBS_INIT}).
After grokking
the code a bit further I'm now guessing this -pthread
argument is
technically accepted by the linker and not needed by the
compiler, but it
would be nice to know this for sure to ensure the
documentation is correct.
gcc says:
-pthread
Adds support for multithreading with the pthreads
library. This
option sets flags for both the preprocessor and
linker.
So it may work to only use it during linking but this may
cause subtle failure
on some platforms.
When writing FindThreads.cmake, it would be better to really
rewrite it and
use the common naming standards for cmake modules.
I'm hesitant to rewrite anything that works, especially if it works on
platforms I don't have access too. :)
Include library variables probably could be added if it can be done
in a safe way with the compile checks already in place.
Not sure on -pthread, we've never added it to our gcc command lines
before. Looking at the man page, it's only a compile flag under
IA-64, RS-6000, PPC, and SPARC. Would recommending people add it to
their compiler flags and only rely on the output of
${CMAKE_THREAD_LIBS_INIT} for linking be the right thing to do?
--
Philip Lowman
Hmm, don't know if the documentation is correct.
I tested this on Linux x86_64 (gcc 4.3) and on an old i686 (gcc 3.2). On
both systems, when I diff the output of 'gcc -E -dM' and 'gcc -E -dM
-pthread' I get '#define _REENTRANT 1'.
So, -pthread clearly defines an extra preprocessor variable.
Marcel Loose
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to set CPACK_PACKAGE_VERSION from a gengetopt configuration file
2009/9/21 Yegor Yefremov yegor_s...@visionsystems.de: Hello, I use gengetopt to generate command line parser for my application. The configuration file *.ggo also specifies programs version like this: # Name of your program package hwtest # don't use package if you're using automake # Version of your program version 1.2.1 # don't use version if you're using automake I'd like to automatically extract these version numbers and assign them to CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH What were the best solution for my problem? I would say that the simplest solution is to keep those number in your CMakeLists.txt and use CONFIGURE_FILE(yourfile.ggo.in yourfile.ggo @ONLY) yourfile.ggo.in could then contain: # Name of your program package hwtest # don't use package if you're using automake # Version of your program version @package_version_ma...@.@package_version_mi...@.@PACKAGE_VERSION_PATCH@ # don't use version if you're using automake or even # Name of your program package hwtest # don't use package if you're using automake # Version of your program version @PACKAGE_VERSION@ # don't use version if you're using automake alternatively you can use a config.h which contains a VERSION macro and compile your gengetopt generated C files with -DHAVE_CONFIG_H=1 (just add ADD_DEFINITION(-DHAVE_CONFIG_H=1) to your CMakeLists.txt) in this second case YOU MUST NOT define version inside *.ggo because the VERSION will comes from config.h. I use the latter method because it was the method used by our previous autotools build system. Choosing between those 2 is a matter of taste. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to set CPACK_PACKAGE_VERSION from a gengetopt configuration file
Hello, I use gengetopt to generate command line parser for my application. The configuration file *.ggo also specifies programs version like this: # Name of your program package hwtest # don't use package if you're using automake # Version of your program version 1.2.1 # don't use version if you're using automake I'd like to automatically extract these version numbers and assign them to CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH What were the best solution for my problem? I would say that the simplest solution is to keep those number in your CMakeLists.txt and use CONFIGURE_FILE(yourfile.ggo.in yourfile.ggo @ONLY) yourfile.ggo.in could then contain: # Name of your program package hwtest # don't use package if you're using automake # Version of your program version @package_version_ma...@.@package_version_mi...@.@PACKAGE_VERSION_PATCH@ # don't use version if you're using automake or even # Name of your program package hwtest # don't use package if you're using automake # Version of your program version @PACKAGE_VERSION@ # don't use version if you're using automake alternatively you can use a config.h which contains a VERSION macro and compile your gengetopt generated C files with -DHAVE_CONFIG_H=1 (just add ADD_DEFINITION(-DHAVE_CONFIG_H=1) to your CMakeLists.txt) in this second case YOU MUST NOT define version inside *.ggo because the VERSION will comes from config.h. I use the latter method because it was the method used by our previous autotools build system. Choosing between those 2 is a matter of taste. Thank you for the hint. I'll try this. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Copying files to runtime directory
Hi, In Windows, we need to copy a bunch of files (dlls and other runtime dependencies) to the runtime directory, mostly belonging to external dependencies. Those files are different for debug and release builds. So I created a function to do just that. I came across several problems or limitations in cmake while doing that. Here is how I did it, and some remarks for each step - For a certain external dependency, I look for a specific platform-dependent directory, with some shared files, and some only for debug or release builds. I have to exclude certain files and directories (.svn directories in this case). It would be nice to have an EXCLUDE parameter for the file(GLOB* functions, like in the install function. I worked around this by iterating over all the files in the list and removing them when they match a certain REGEX. - I wanted to create post-build command to copy the necessary files after building, because they are only needed when actually running/debugging the application. There currently is no way to generate different custom commands for different configurations. I could work around this by using some if-tests inside the custom command itself, but I decided against it because it would be too Visual Studio-specific. - So I copy all files to each build directory (one for each configuration that is generated, mind that for Visual Studio no build configuration is chosen at configure time) in cmake. This of course is not very optimal, as it copies the files for all configurations, also the ones I will probably never build. Here I used the cmake command with -E copy_if_different. This works, but spawns a new process for each file to be copied. I could use configure_file, but that seemed a bit hacky to me. All in all, my method works, but to summarize, the following features would be a nice addition to cmake: - an EXCLUDE parameter for the file globbing commands - configuration-specific custom commands - a cmake command to copy files (with a parameter to only do it when the files differ) Greetz, JeDi ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.4 won't find boost 1.40 on windows
2009/9/21 Philip Lowman phi...@yhbt.com:
Ultimately we can add anything to the search path of FindBoost that makes
sense. If you have suggestions, please feel free to submit them (preferably
with a tested patch) to the bugtracker.
In preparation of this, could you please clarify which file structure
FindBoost expects in the folders rooted at the entries in
_boost_INCLUDE_SEARCH_DIRS?
With Boost 1.40.0 installed via bjam --prefix=C:\Programme\boost, the
following structure is created:
C:\Programme
+-boost
+-include
| +-boost-1_40
| +-boost
| +-config.hpp (etc.)
+-lib
+-boost_date_time-vc90-mt-1_40.dll (etc.)
This, however, would require the following patch (against 2.6.4).
Ingolf
--- FindBoost.cmake.orig2009-09-21 14:34:44.0 +0200
+++ FindBoost.cmake 2009-09-21 15:01:19.0 +0200
@@ -271,7 +271,7 @@
# The user has not requested an exact version. Among known
# versions, find those that are acceptable to the user request.
set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
-1.38.0 1.38 1.37.0 1.37
+1.40.0 1.40 1.38.0 1.38 1.37.0 1.37
1.36.1 1.36.0 1.36 1.35.1 1.35.0 1.35 1.34.1 1.34.0
1.34 1.33.1 1.33.0 1.33)
set(_boost_TEST_VERSIONS)
@@ -380,7 +380,7 @@
SET(_boost_INCLUDE_SEARCH_DIRS
C:/boost/include
C:/boost
-$ENV{ProgramFiles}/boost
+$ENV{ProgramFiles}/boost/include
/sw/local/include
)
@@ -639,7 +639,7 @@
C:/boost/lib
C:/boost
$ENV{ProgramFiles}/boost/boost_${Boost_MAJOR_VERSION}_${Boost_MINOR_VERSION}_${Boost_SUBMINOR_VERSION}/lib
-$ENV{ProgramFiles}/boost
+$ENV{ProgramFiles}/boost/lib
/sw/local/lib
)
IF( BOOST_ROOT )
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Custom Command Execution
Hi,
I have the following CMakeLists.txt:
-
cmake_minimum_required(VERSION 2.6)
MESSAGE ( CMAKE TEST )
ADD_CUSTOM_COMMAND (TARGET Hello PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E echo Prebuild execution
COMMENT Information string for prebuild execution
)
ADD_EXECUTABLE ( Hello abc.cpp )
-
Why is the custom command not executed? Is it meat different?
- Tom
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ctest and CxxTest
We tackled this using a hack-ish CMake command for Google Tests that found all our tests in the source code, and generated CTest commands for them. You could do a similar thing on a test suite. Details are here: http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage#Google_Test -dan On 9/20/09 10:40 AM, Wojciech Migda wojtek.g...@interia.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Lowman pisze: You could split up your testcases into multiple CxxTest classes. You could check to see if the cxxtest code generator supports preprocessor statements in generating test runners. Then you could group your tests by #ifdef / #endif...? Alternatively if it's not supported you may be able to modify the code generator to output multiple runners depending on the tests you want to run, e.g. cxxtestgen.pl --enable-test foo I think splitting things up probably would be the easiest approach. On Sun, Sep 20, 2009 at 10:01 AM, Wojciech Migda wojtek.g...@interia.pl wrote: Hi all, I was wondering about an improvement for the way CxxTest unit tests are coupled with CTest. Right now when CTest submits results to CDash the tests are counted by binaries executed. In my unit tests each binary corresponds to an entire suite (approx. 150 testcases grouped within single CxxTest class). I'd see it very useful to have CTest operate with CxxTest based unit tests on a testcase level. Has anyone stumbled upon similar problem and got ideas / solutions ? Thanks for assistance, -Wojciech Indeed, splitting is the easiest approach, albeit it adds additional effort - when a new test is added to a suite CMakeLists.txt has to be updated accordingly. If my idea how CTest works when it uploads results to CDash is correct then it only looks at the return code of the executed binary and captures its output. What if there was an option for CTest to work in a multiple-testcases mode where the output returned by the executed binary would be formatted in a way so as CTest would be able to parse it and process into CDash xml files with information on all tests executed. Just a thought, I have no idea how complicated that would turn out to be. I also thought about the binary itself being able to run single testcases on the basis of command line arguments, but that would require parallel information being stored in CMakeLists.txt, which again add effort. I'll see if I have more ideas. Thanks, - -Wojtek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKtkz70iFl+nAyImcRAsPSAJ4yMjKSb96NZ02awttzwwu/nHZRhgCfQ2KZ VEM63SdgrUUA4OIXGApKJd8= =4utB -END PGP SIGNATURE- -- Bezplatne konto i limit do 100 tys. Otwierasz? http://link.interia.pl/f2342 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Daniel Blezek, PhD Medical Imaging Informatics Innovation Center P 127 or (77) 8 8886 T 507 538 8886 E blezek.dan...@mayo.edu Mayo Clinic 200 First St. S.W. Harwick SL-44 Rochester, MN 55905 mayoclinic.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom Command Execution
2009/9/21 th@gmx.de:
Hi,
I have the following CMakeLists.txt:
-
cmake_minimum_required(VERSION 2.6)
MESSAGE ( CMAKE TEST )
ADD_CUSTOM_COMMAND (TARGET Hello PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E echo Prebuild execution
COMMENT Information string for prebuild execution
)
ADD_EXECUTABLE ( Hello abc.cpp )
-
Why is the custom command not executed? Is it meat different?
From my testing side (CMake 2.6.4 / Unix Makefile / Linux )
it looks like you need to put your ADD_CUSTOM_COMMAND definition
AFTER the ADD_EXECUTABLE statement.
May be this deserves a bug report since when you write it before it
behaves as silently ignored.
Note that on Linux the doc is right:
Note that the PRE_BUILD option is only supported on Visual Studio 7 or
later. For all other generators PRE_BUILD will be treated as
PRE_LINK.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom Command Execution
Hey Eric,
Hi,
I have the following CMakeLists.txt:
-
cmake_minimum_required(VERSION 2.6)
MESSAGE ( CMAKE TEST )
ADD_CUSTOM_COMMAND (TARGET Hello PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E echo Prebuild
execution
COMMENT Information string for prebuild
execution
)
ADD_EXECUTABLE ( Hello abc.cpp )
-
Why is the custom command not executed? Is it meat different?
From my testing side (CMake 2.6.4 / Unix Makefile / Linux )
it looks like you need to put your ADD_CUSTOM_COMMAND definition
AFTER the ADD_EXECUTABLE statement.
May be this deserves a bug report since when you write it before it
behaves as silently ignored.
Note that on Linux the doc is right:
Note that the PRE_BUILD option is only supported on Visual Studio 7 or
later. For all other generators PRE_BUILD will be treated as
PRE_LINK.
It works this way round!
THX - tom
BTW: I got flex/bison to run (It was the PATH and a system restart) - thanks
for that, too!
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying files to runtime directory
On Mon, Sep 21, 2009 at 02:54:04PM +0200, Jeroen Dierckx wrote: In Windows, we need to copy a bunch of files (dlls and other runtime dependencies) to the runtime directory, mostly belonging to external dependencies. Those files are different for debug and release builds. So I created a function to do just that. I came across several problems or limitations in cmake while doing that. Here is how I did it, and some remarks for each step I posted a thread last Thursday with similar questions. The short version, I think, is that you really want to use install() for these kinds of operations. install() already knows how to EXCLUDE, copy files on a per-configuration basis, and update files when they are out-of-date. If you don't use install(), I think the types of hacks you mentioned (copy all files, debug and release; manually handle exclusions) are the only way to do what you want. tyler ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom Command Execution
On Mon, Sep 21, 2009 at 4:15 PM, Eric Noulard eric.noul...@gmail.com wrote:
2009/9/21 th@gmx.de:
Hi,
I have the following CMakeLists.txt:
-
cmake_minimum_required(VERSION 2.6)
MESSAGE ( CMAKE TEST )
ADD_CUSTOM_COMMAND (TARGET Hello PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E echo Prebuild execution
COMMENT Information string for prebuild execution
)
ADD_EXECUTABLE ( Hello abc.cpp )
-
Why is the custom command not executed? Is it meat different?
From my testing side (CMake 2.6.4 / Unix Makefile / Linux )
it looks like you need to put your ADD_CUSTOM_COMMAND definition
AFTER the ADD_EXECUTABLE statement.
This is normal, because you specify a target (that has to exist) to
add the custom command to. IIRC, this is the case for all
target-specific commands and variables.
May be this deserves a bug report since when you write it before it
behaves as silently ignored.
I agree, a warning or error should be raised if the specified target
doesn't exist.
Note that on Linux the doc is right:
Note that the PRE_BUILD option is only supported on Visual Studio 7 or
later. For all other generators PRE_BUILD will be treated as
PRE_LINK.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying files to runtime directory
On Mon, Sep 21, 2009 at 5:29 PM, Tyler Roscoe ty...@cryptio.net wrote: On Mon, Sep 21, 2009 at 02:54:04PM +0200, Jeroen Dierckx wrote: In Windows, we need to copy a bunch of files (dlls and other runtime dependencies) to the runtime directory, mostly belonging to external dependencies. Those files are different for debug and release builds. So I created a function to do just that. I came across several problems or limitations in cmake while doing that. Here is how I did it, and some remarks for each step I posted a thread last Thursday with similar questions. The short version, I think, is that you really want to use install() for these kinds of operations. install() already knows how to EXCLUDE, copy files on a per-configuration basis, and update files when they are out-of-date. If you don't use install(), I think the types of hacks you mentioned (copy all files, debug and release; manually handle exclusions) are the only way to do what you want. I understand your reasoning, but I don't completely agree. We do use the install commands, but for preparing the build for packaging. That way, we can use cpack later on to release our SDK or applications. The problem is that I have to build the install target every time I want to debug something, which is not exactly ideal. But maybe doing that is easier than what I am trying to achieve now :-) How do other windows users do this kind of thing? The problem is that, when linking with external dynamic libraries, the dlls belonging to that library have to be in the runtime directory in order for the application to start. One of the problems I have with using install for this, is that I don't want to clutter the install directory with files generated at runtime. Also, I'm not sure Visual Studio would find all debug files (which are not installed, so inside the build directories). But I am going to try this method and see how it works out. Thanks for the info! Greetings, JeDi ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compiling arm-elf on Windows host
On Monday 21 September 2009, Harald Kipp wrote: Alexander Neundorf wrote: On Sunday 20 September 2009, Harald Kipp wrote: Alexander Neundorf wrote: On Sunday 20 September 2009, Harald Kipp wrote: add_library(nutfs STATIC basename dirent dirname) I would recommend to use the full filename, i.e. including the suffix. So probably basename.c etc. Oops, I temporarily removed the extensions after finding make target extensions like .c.o. Scanning dependencies of target nutfs [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj Das System kann den angegebenen Pfad nicht finden. Try VERBOSE=1 make to see the full command which is executed. I'll try to do this tommorrow. As expected, make fails at the cd command using slashes instead of backslashes: [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj cd C:/ethernut-4.9.6/nutbld/fs C:/Programme/yagarto/bin/arm-elf-gcc.exe-o CMakeFiles/nutfs.dir/basename.c.obj -c C:/ethernut-4.9.6/nut/fs/basename.c Das System kann den angegebenen Pfad nicht finden. (English: The system cannot find the specified path) Is this the make from yagarto ? make[2]: *** [fs/CMakeFiles/nutfs.dir/basename.c.obj] Error 1 make[2]: Leaving directory `C:/ethernut-4.9.6/nutbld' make[1]: *** [fs/CMakeFiles/nutfs.dir/all] Error 2 make[1]: Leaving directory `C:/ethernut-4.9.6/nutbld' make: *** [all] Error 2 You might try the nmake makefiles in case you have nmake. I'll try this as well. Unfortunately no luck. The generated Makefiles cannot be processed by GNU make, because nmake partly uses a different syntax, like !IF $(OS) == Windows_NT NULL= !ELSE NULL=nul !ENDIF Furthermore it adds the /nologo command line option when calling $(MAKE), which is rejected by GNU make. Yes, you would have to use nmake to process these makefiles. Which makefile generator do you use ? Unix Makefiles ? There are also MinGW Makefiles and MSYS Makefiles. I don't have a Windows here, so I can't test. These three generators all generate makefiles for GNU make under Windows, but differ in things like the directory separators etc. From the docs for the MinGW one: Generates a make file for use with mingw32-make.; The makefiles generated use cmd.exe as the shell. They do not require msys or a unix shell.; and for the MSYS one: Generates MSYS makefiles.; The makefiles use /bin/sh as the shell. They require msys to be installed on the machine.; So the MSYS one is probably not what you want, but MinGW sounds good. Please give it a try. So, you only have a problem with finding the right combination of makefile generator and build tools :-) Here you can find a bit more information: http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#Makefile_generators One reason for looking at CMake as an alternative to GNU autotools is, that we do not want to force Windows users to install Cygwin or force OS X users to install fink. It'd be great if CMake can help here. Should do. Sigh. Right now I do not see the light at the end of the tunnel. May be I should explain my goal in more detail. Our package exists of the RTOS source code, which may be build for different targets (AVR, ARM, AVR32). Furthermore it contains the source code of the Configurator tool, which creates several C header files and Makefiles based on a target board config file. Running these makefiles will create the RTOS for this specific target board. Btw. the Configurator is based on the wxWidgets version of the eCos configtool, but we replaced tcl by Lua. On Linux and OS X we use GNU autotools to create the Configurator executable. On Windows there is no such capability and the average user must stick with the pre-build executable. Then the Configurator must be executed manually to create the header and Makefile files. Finally make will create the target binaries. These steps are equal on all host platforms. We could have used autotools to create the target binaries as well, but not on Windows without installing a *nix environment. The idea is to use CMake to automatically to 1. build the Configurator tool binary, checking the compiler available, wxWidgets version etc. The first step must be separate from the two following, since it uses a different toolchain, and one buildtree in CMake must (really really should) use only one toolchain. 2. run the Configurator for a specified target board, creating the C headers and possibly one or more .cmake files for building the target binaries 3. build the RTOS and sample applications, checking the cross compiler, target run time library etc. This should work. We just need to get your makefiles work at all. Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at:
[CMake] ctest - Can it make DESTDIR=./test_dir install to a dir and run tests there?
I have a project that I want to use cmake with, but the project builds several DLL's and uses several .pem certificates that all need to be in the same directory before the application can run. As things stand right now, I run nmake test and all my tests fail because my application doesn't have all of the dependencies it needs to run. If I run a nmake install it puts all the dependencies where they belong and the program runs. Is there any way of telling ctest that I want to do a nmake DESTDIR=./test_dir install and then run all the ctests from the applications installed into that directory? -- Shane ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying files to runtime directory
On Mon, Sep 21, 2009 at 05:48:38PM +0200, Jeroen Dierckx wrote:
We do use the install commands, but for preparing the build for
packaging. That way, we can use cpack later on to release our SDK or
applications. The problem is that I have to build the install target
every time I want to debug something, which is not exactly ideal. But
maybe doing that is easier than what I am trying to achieve now :-)
If you don't want to train your users to build the INSTALL target rather
than doing Build Solution or whatever, you might be able to cheat by
running the install() stuff as a custom command. I think this worked for
me as a test:
add_custom_target (fake_install
ALL
${CMAKE_COMMAND} -P cmake_install.cmake
)
The use of ALL there is debatable, I suppose. You could also use
add_dependencies to cause this install rule to run as part of any other
buildable.
How do other windows users do this kind of thing? The problem is that,
when linking with external dynamic libraries, the dlls belonging to
that library have to be in the runtime directory in order for the
application to start.
Today, we copy things manually like you seem to do.
In the future, I'd like to set up install() rules to handle this sort of
thing. I'd also like to make use of BundleUtilities and
GetPrerequisites, which are supposed to help with problems like getting
all the runtimes needed by my project.
One of the problems I have with using install for this, is that I
don't want to clutter the install directory with files generated at
runtime. Also, I'm not sure Visual Studio would find all debug files
(which are not installed, so inside the build directories). But I am
going to try this method and see how it works out.
I don't understand this part.
If the runtimes are needed to run the installed application, how can
they be considered clutter?
What debug files are you talking about?
tyler
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ctest and CxxTest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Blezek pisze: We tackled this using a hack-ish CMake command for Google Tests that found all our tests in the source code, and generated CTest commands for them. You could do a similar thing on a test suite. Details are here: http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage#Google_Test -dan Thank you very much - this is pretty much the idea I started converging to. What you've done with ITK will work 100%. I just need to tweak the CxxTest generator script. BR, - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKt8Rm0iFl+nAyImcRAl3yAJ9oSp7Cj5CvVfjvq9wiUQjGmnqQGgCePT/o VdtdcPqeZgOzqBw2r+Aox5E= =v868 -END PGP SIGNATURE- -- Zobacz jak mieszka Kasia Zielinska! Kliknij http://link.interia.pl/f2343 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest - Can it make DESTDIR=./test_dir install to a dir and run tests there?
On Mon, Sep 21, 2009 at 11:04:47AM -0600, Dixon, Shane wrote: I have a project that I want to use cmake with, but the project builds several DLL's and uses several .pem certificates that all need to be in the same directory before the application can run. As things stand right now, I run nmake test and all my tests fail because my application doesn't have all of the dependencies it needs to run. If I run a nmake install it puts all the dependencies where they belong and the program runs. The other thread I just posted in talks about some of the details about copying runtime files around during installation. Is there any way of telling ctest that I want to do a nmake DESTDIR=./test_dir install and then run all the ctests from the applications installed into that directory? I posted a sample add_custom_target in the other thread whereby you can cause install rules to run during build time. Maybe that will get you started? Otherwise, you could write a wrapper script that sets up the environment you need and then runs CTest. You can even use add_test() so that CTest will run your wrapper script for you when it runs. tyler ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode paths not turning out right
I don't have a sample project ready yet, but I will provide the generated
xcode project files in case you guys want to take a look at them. Open them
in a text editor and you'll see that the paths are weird. Relative files
appear as:
projects/Newton/source/SpawnShadowEntityAction.cpp
This seems wrong. It should be:
source/SpawnShadowEntityAction.cpp
-
Robert Dailey
On Fri, Sep 18, 2009 at 4:16 PM, Robert Dailey rcdai...@gmail.com wrote:
I'll see if I can get you guys a reproducible project. However, I hope you
guys have access to the version of xcode I'm using. I'll also get you the
version number next monday when I get back into work.
On Fri, Sep 18, 2009 at 4:15 PM, Robert Dailey rcdai...@gmail.com wrote:
Yeah, that's what I'm doing... basically:
# Root CMakeLists.txt file:
function( func1 file )
add_executable( foobar ${CMAKE_CURRENT_SOURCE_DIR}/${file} )
endfunction()
function( define_project file )
func1( ${file} )
endfunction()
# CMakeLists.txt in a lower subdirectory (Inside foobar project
directory):
define_project()
The code above isn't exactly what I'm running, but more of a simplified
version. The goal here was to turn each source file into an absolute path by
prepending the CMAKE_CURRENT_SOURCE_DIR to it. When I print the path out
from the cmake script via message() it seems to be OK.
-
Robert Dailey
On Fri, Sep 18, 2009 at 3:15 PM, David Cole david.c...@kitware.comwrote:
Sounds like maybe you are using ${CMAKE_CURRENT_SOURCE_DIR} in a
function or macro. (defined at the top level, but called from a lower
level)...
On Fri, Sep 18, 2009 at 4:12 PM, Brad King brad.k...@kitware.comwrote:
Robert Dailey wrote:
Where is the CMakeLists.txt file containing this line?
Perhaps /Users/imac/work/redsword/CMakeLists.txt?
That's where the root one is, and this root script has all of the meat
that the subdirectories call. This script is the one that has the
functions
that call add_executable() with the absolute paths. However, the script
*calling* that function is in:
/Users/imac/work/redsword/projects/foobar/CMakeLists.txt
I'm having trouble reproducing this. I have
# CMakeLists.txt
cmake_minimum_required(VERSION 2.6) # but I'm running 2.7.20090918
project(FOO C)
function(my_add)
add_executable(${ARGN})
endfunction()
add_subdirectory(A)
# A/CMakeLists.txt
my_add(foo ${FOO_SOURCE_DIR}/A/foo.mm foo.c)
In Xcode, the Get Info dialog for foo.mm says
Name: A/foo.mm
Full path: /path/to/source/tree/A/foo.mm
What is the symptom you're seeing?
Can you please send me a tarball with a minimal project?
The version of xcode I'm using is the one that comes with the iPhone
3.1 SDK installer. I don't know how to find out the version number of
xcode
on the mac. I think it is xcode 3.1 though.
Use the Xcode menu:
Xcode - About Xcode
to see a version dialog.
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Resolution of dependencies for Subversion
Hello! A configuration script on my Linux system contains the following information. # $Id: FindSubversion.cmake,v 1.2.2.3 2008-05-23 20:09:34 hoffman Exp $ http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindSubversion.cmake?revision=1.4root=CMakeview=markup I have got the impression that there will not be any variables defined with the suffix _INCLUDES and _LIBS. I would expect such names so that they can be used for the commands INCLUDE_DIRECTORIES and LINK_DIRECTORIES. http://cmake.org/cmake/help/cmake2.6docs.html#command:include_directories Subversion has got additional software dependencies like it is described in the document Using the APIs - Chapter 8. Developer Information. I have also got some problems to get the commands FIND_PACKAGE(APR REQUIRED) and FIND_PACKAGE(APRUtil 1.3 REQUIRED) to work so that the Apache Portable Runtime library can be used as expected. Do any scripts need further improvements and fine-tuning? Regards, Markus ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode paths not turning out right
My paths are correct. I'm passing in the correct absolute paths into
add_executable. I think that cmake is using the current cmake file instead
of using the one that the function call originated from. For example, I have
two CMake scripts:
/Users/imac/work/redsword/CMakeLists.txt
/Users/imac/work/redsword/projects/Newton/CMakeLists.txt
The former script is the one that has the function:
function( define_project )
add_executable( )
endfunction()
And the latter script calls the define_project() function. Can anyone peek
at the CMake source to see if this is indeed the case? Again, I'll try to
find time to provide a reproducible test project.
-
Robert Dailey
On Mon, Sep 21, 2009 at 1:26 PM, Robert Dailey rcdai...@gmail.com wrote:
I don't have a sample project ready yet, but I will provide the generated
xcode project files in case you guys want to take a look at them. Open them
in a text editor and you'll see that the paths are weird. Relative files
appear as:
projects/Newton/source/SpawnShadowEntityAction.cpp
This seems wrong. It should be:
source/SpawnShadowEntityAction.cpp
-
Robert Dailey
On Fri, Sep 18, 2009 at 4:16 PM, Robert Dailey rcdai...@gmail.com wrote:
I'll see if I can get you guys a reproducible project. However, I hope you
guys have access to the version of xcode I'm using. I'll also get you the
version number next monday when I get back into work.
On Fri, Sep 18, 2009 at 4:15 PM, Robert Dailey rcdai...@gmail.comwrote:
Yeah, that's what I'm doing... basically:
# Root CMakeLists.txt file:
function( func1 file )
add_executable( foobar ${CMAKE_CURRENT_SOURCE_DIR}/${file} )
endfunction()
function( define_project file )
func1( ${file} )
endfunction()
# CMakeLists.txt in a lower subdirectory (Inside foobar project
directory):
define_project()
The code above isn't exactly what I'm running, but more of a simplified
version. The goal here was to turn each source file into an absolute path by
prepending the CMAKE_CURRENT_SOURCE_DIR to it. When I print the path out
from the cmake script via message() it seems to be OK.
-
Robert Dailey
On Fri, Sep 18, 2009 at 3:15 PM, David Cole david.c...@kitware.comwrote:
Sounds like maybe you are using ${CMAKE_CURRENT_SOURCE_DIR} in a
function or macro. (defined at the top level, but called from a lower
level)...
On Fri, Sep 18, 2009 at 4:12 PM, Brad King brad.k...@kitware.comwrote:
Robert Dailey wrote:
Where is the CMakeLists.txt file containing this line?
Perhaps /Users/imac/work/redsword/CMakeLists.txt?
That's where the root one is, and this root script has all of the meat
that the subdirectories call. This script is the one that has the
functions
that call add_executable() with the absolute paths. However, the script
*calling* that function is in:
/Users/imac/work/redsword/projects/foobar/CMakeLists.txt
I'm having trouble reproducing this. I have
# CMakeLists.txt
cmake_minimum_required(VERSION 2.6) # but I'm running 2.7.20090918
project(FOO C)
function(my_add)
add_executable(${ARGN})
endfunction()
add_subdirectory(A)
# A/CMakeLists.txt
my_add(foo ${FOO_SOURCE_DIR}/A/foo.mm foo.c)
In Xcode, the Get Info dialog for foo.mm says
Name: A/foo.mm
Full path: /path/to/source/tree/A/foo.mm
What is the symptom you're seeing?
Can you please send me a tarball with a minimal project?
The version of xcode I'm using is the one that comes with the iPhone
3.1 SDK installer. I don't know how to find out the version number of
xcode
on the mac. I think it is xcode 3.1 though.
Use the Xcode menu:
Xcode - About Xcode
to see a version dialog.
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying files to runtime directory
On Monday 21 September 2009 09:48:38 am Jeroen Dierckx wrote: On Mon, Sep 21, 2009 at 5:29 PM, Tyler Roscoe ty...@cryptio.net wrote: On Mon, Sep 21, 2009 at 02:54:04PM +0200, Jeroen Dierckx wrote: In Windows, we need to copy a bunch of files (dlls and other runtime dependencies) to the runtime directory, mostly belonging to external dependencies. Those files are different for debug and release builds. So I created a function to do just that. I came across several problems or limitations in cmake while doing that. Here is how I did it, and some remarks for each step I posted a thread last Thursday with similar questions. The short version, I think, is that you really want to use install() for these kinds of operations. install() already knows how to EXCLUDE, copy files on a per-configuration basis, and update files when they are out-of-date. If you don't use install(), I think the types of hacks you mentioned (copy all files, debug and release; manually handle exclusions) are the only way to do what you want. I understand your reasoning, but I don't completely agree. We do use the install commands, but for preparing the build for packaging. That way, we can use cpack later on to release our SDK or applications. The problem is that I have to build the install target every time I want to debug something, which is not exactly ideal. But maybe doing that is easier than what I am trying to achieve now :-) How do other windows users do this kind of thing? The problem is that, when linking with external dynamic libraries, the dlls belonging to that library have to be in the runtime directory in order for the application to start. I don't know about your setup, but for our apps, our developers just set the PATH environment variable for their dlls not built as part of the project. Clint ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode paths not turning out right
Robert Dailey wrote: My paths are correct. I'm passing in the correct absolute paths into add_executable. I think that cmake is using the current cmake file instead of using the one that the function call originated from. For example, I have two CMake scripts: /Users/imac/work/redsword/CMakeLists.txt /Users/imac/work/redsword/projects/Newton/CMakeLists.txt The former script is the one that has the function: function( define_project ) add_executable( ) endfunction() And the latter script calls the define_project() function. Can anyone peek at the CMake source to see if this is indeed the case? Again, I'll try to find time to provide a reproducible test project. By the time the Xcode generator writes the path, there is no distinction between add_executable being called from the CMakeLists.txt directly or through the function. If you message() out the path inside your function just before or after add_executable, that is the path the generator will see. I expect it is correct, and the generator or Xcode does something funnyespecially since it works in VS. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode paths not turning out right
On Mon, Sep 21, 2009 at 2:48 PM, Robert Dailey rcdai...@gmail.com wrote: On Mon, Sep 21, 2009 at 1:43 PM, Brad King brad.k...@kitware.com wrote: Robert Dailey wrote: My paths are correct. I'm passing in the correct absolute paths into add_executable. I think that cmake is using the current cmake file instead of using the one that the function call originated from. For example, I have two CMake scripts: /Users/imac/work/redsword/CMakeLists.txt /Users/imac/work/redsword/projects/Newton/CMakeLists.txt The former script is the one that has the function: function( define_project ) add_executable( ) endfunction() And the latter script calls the define_project() function. Can anyone peek at the CMake source to see if this is indeed the case? Again, I'll try to find time to provide a reproducible test project. By the time the Xcode generator writes the path, there is no distinction between add_executable being called from the CMakeLists.txt directly or through the function. If you message() out the path inside your function just before or after add_executable, that is the path the generator will see. I expect it is correct, and the generator or Xcode does something funnyespecially since it works in VS. I've attached a test project that reproduces this issue. At the root test directory, create a new directory called 'build'. So you will have test/build. cd into test/build and run: cmake -G Xcode .. This will generate an xcode project for you. Open that, and right click on main.cpp (which should be colored red because it is an invalid path) and click Get Info. Look at the path. It's totally wrong. Oh yeah, and I'm using Xcode v3.1.4 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode paths not turning out right
Robert Dailey wrote: I've attached a test project that reproduces this issue. At the root test directory, create a new directory called 'build'. So you will have test/build. cd into test/build and run: cmake -G Xcode .. This will generate an xcode project for you. Open that, and right click on main.cpp (which should be colored red because it is an invalid path) and click Get Info. Look at the path. It's totally wrong. Great, thanks. Now I see the problem. In fact it happens even if I manually expand the function inline in the subdir. The key is that the Xcode project file is in a subdir and not the top. This was in fact caused by the patch for the bug I linked earlier in this thread: http://www.cmake.org/Bug/view.php?id=8481 In order to help Xcode 3.0 set breakpoints the project file needs to reference sources with relative paths. The fix for that bug always converts paths relative to the top of the tree instead of the directory containing the Xcode project file. It went unnoticed because usually these are the same. I'm going to re-open that issue with a link to this message. Thanks, -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Non-recursive makefiles
Hi, I searched the cmake list archive and found a reference in 2004 about modifying cmake to generate non-recursive makefiles: On Jan 30, 2004, at 2:44 PM, William A. Hoffman wrote: * Right now there is no way to create non-recursive makefiles.** We have some plans to create non-recursive makefiles. However,** I am not sure one large makefile will scale for larger projects.** We have had problems with make on various systems and large files, or** too many dependencies. We have seen that problem even with the** recursive make that we use. So, I don't really agree with the paper** on that point. If you are interested in trying a non-recursive** generator, I could point you at the right places in the code.** It would involve creating new class like ** cmLocalUnixMakefileGenerator.cxx.* Has anyone done any work in this area? A year ago I migrated our build system to cmake. Using distcc and a distributed build farm, we were able to reduce build time on linux from over an hour to about 5 minutes. I'm now looking for opportunities to reach the next level of build performance. One thing I identified is that with generated recursive make files we can only send compile jobs out one directory at a time. I'm hoping that with a non-recursive make file we'll be able to send a higher number of independent source files out to the build farm in parallel. I'm open to contributing code if no one has done it yet. Thanks, Sahn ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode paths not turning out right
On Mon, Sep 21, 2009 at 4:03 PM, Brad King brad.k...@kitware.com wrote: Robert Dailey wrote: I've attached a test project that reproduces this issue. At the root test directory, create a new directory called 'build'. So you will have test/build. cd into test/build and run: cmake -G Xcode .. This will generate an xcode project for you. Open that, and right click on main.cpp (which should be colored red because it is an invalid path) and click Get Info. Look at the path. It's totally wrong. Great, thanks. Now I see the problem. In fact it happens even if I manually expand the function inline in the subdir. The key is that the Xcode project file is in a subdir and not the top. This was in fact caused by the patch for the bug I linked earlier in this thread: http://www.cmake.org/Bug/view.php?id=8481 In order to help Xcode 3.0 set breakpoints the project file needs to reference sources with relative paths. The fix for that bug always converts paths relative to the top of the tree instead of the directory containing the Xcode project file. It went unnoticed because usually these are the same. I'm going to re-open that issue with a link to this message. Great! Glad I could help. Let me know when this is fixed so I can download a new nightly build. I'll try to keep up with that bug status as well. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying files to runtime directory
On Mon, Sep 21, 2009 at 12:37:06PM -0600, Clinton Stimpson wrote: I don't know about your setup, but for our apps, our developers just set the PATH environment variable for their dlls not built as part of the project. This works well for developers but often works less well for testers, or for making sure that our built packages have all the runtimes they need and can run on a virgin machine. It's also nice if the local CMake system can take care of the dependencies because then upgrading a thirdparty library is just setting a new path or new version number in the CMake system and it works for everyone. If we rely on PATH instead, then each developer has to do work every time we change a 3rdparty dependency. Just some notes on why we, and presumably others, often want to do things like those described in the OP. tyler ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Resolution of dependencies for Subversion
On Mon, Sep 21, 2009 at 08:15:47PM +0200, SF Markus Elfring wrote: A configuration script on my Linux system contains the following information. # $Id: FindSubversion.cmake,v 1.2.2.3 2008-05-23 20:09:34 hoffman Exp $ http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindSubversion.cmake?revision=1.4root=CMakeview=markup You mean that you have FindSubversion.cmake as part of your CMake installation? Or something else? I have got the impression that there will not be any variables defined with the suffix _INCLUDES and _LIBS. I would expect such names so that they can be used for the commands INCLUDE_DIRECTORIES and LINK_DIRECTORIES. http://cmake.org/cmake/help/cmake2.6docs.html#command:include_directories I don't see any variables defined with those names in the module you linked above. What is the question here? Subversion has got additional software dependencies like it is described in the document Using the APIs - Chapter 8. Developer Information. I have also got some problems to get the commands FIND_PACKAGE(APR REQUIRED) and FIND_PACKAGE(APRUtil 1.3 REQUIRED) to work so that the Apache Portable Runtime library can be used as expected. Do any scripts need further improvements and fine-tuning? Now I'm really confused. Are you trying to use CMake to build a Subversion addon of some sort? If so, I don't think that's what FindSubversion is for. It looks like FindSubversion is for running the svn executable during builds in a CMake-friendly way. tyler ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode paths not turning out right
Robert Dailey wrote: Great! Glad I could help. Let me know when this is fixed so I can download a new nightly build. I'll try to keep up with that bug status as well. If you get an account in the bug tracker you can go to the issue and choose monitor issue. Then you will get updates automatically. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying files to runtime directory
On Monday 21 September 2009 03:27:43 pm Tyler Roscoe wrote: On Mon, Sep 21, 2009 at 12:37:06PM -0600, Clinton Stimpson wrote: I don't know about your setup, but for our apps, our developers just set the PATH environment variable for their dlls not built as part of the project. This works well for developers but often works less well for testers, or for making sure that our built packages have all the runtimes they need and can run on a virgin machine. Our nightly build/test machines create packages and posts them for our testers or adventurous users. Packaging it is also a test. If a 3rd party dll doesn't get bundled up and its needed, the test fails (BundleUtilities.cmake has a verification step that helps us catch incomplete packages). It's also nice if the local CMake system can take care of the dependencies because then upgrading a thirdparty library is just setting a new path or new version number in the CMake system and it works for everyone. If we rely on PATH instead, then each developer has to do work every time we change a 3rdparty dependency. Well, that depends on your dependencies and how they are included. We try to put most of them in the source tree so each developer makes their own. Having to deploy multiple binaries for multiple compilers on multiple platforms just for developers isn't fun. So we're down to just a few binary packages that we have to distribute to developers. They don't change often enough for maintainence of the PATH env. variable to be a problem. Clint ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: additional target support
-- Forwarded message -- From: Darren ha nbers...@gmail.com Date: Tue, Sep 22, 2009 at 8:47 AM Subject: Re: [CMake] additional target support To: a.neundorf-w...@gmx.net On Sat, Sep 19, 2009 at 9:00 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Saturday 19 September 2009, Darren ha wrote: Hi list! I was wondering how to implement the following requirements in CMakeLists.txt. - I want to add 2 additional target to each target. - target.only ; only build target without any dependency check Did you try target/fast ? Thanks, this works!! - target.clean ; only clean target. not cleaning dependent targets Isn't the cleaning done only on directory basis ? So I think currently the only way to do what you want is to structure your directories accordingly. this works! any directories containing CMakelists.txt have clean target in Makefile. but this takes additional step(moving to desired directory). is there any simple way to add target.clean ? Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.4 won't find boost 1.40 on windows
On Mon, Sep 21, 2009 at 5:51 AM, Ingolf Steinbach ingolf.steinb...@googlemail.com wrote: 2009/9/21 Philip Lowman phi...@yhbt.com: Thankfully, the changes made to library naming in 1.40 do not break FindBoost. :) Philip, does this apply to the latest release (i.e. cmake 2.6.4)? Or rather the latest revision in CVS? (See also below) Not sure what you mean exactly. I was referring to Boost 1.40 builds removing compiler tags (i.e. -gcc43) for many platforms by default. -- Philip Lowman ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated FindThreads.cmake in tracker
On Mon, Sep 21, 2009 at 6:07 AM, Marcel Loose lo...@astron.nl wrote:
On Sun, 2009-09-20 at 19:32 -0400, Philip Lowman wrote:
On Sun, Sep 20, 2009 at 3:02 PM, Hendrik Sattler
I'm hesitant to rewrite anything that works, especially if it works on
platforms I don't have access too. :)
Include library variables probably could be added if it can be done
in a safe way with the compile checks already in place.
Not sure on -pthread, we've never added it to our gcc command lines
before. Looking at the man page, it's only a compile flag under
IA-64, RS-6000, PPC, and SPARC. Would recommending people add it to
their compiler flags and only rely on the output of
${CMAKE_THREAD_LIBS_INIT} for linking be the right thing to do?
Hmm, don't know if the documentation is correct.
I tested this on Linux x86_64 (gcc 4.3) and on an old i686 (gcc 3.2). On
both systems, when I diff the output of 'gcc -E -dM' and 'gcc -E -dM
-pthread' I get '#define _REENTRANT 1'.
So, -pthread clearly defines an extra preprocessor variable.
We've always defined _REENTRANT manually and specified -lpthread but looking
into this further I'm guessing we're just getting lucky since we've never
built on platforms where this doesn't work.
http://stackoverflow.com/questions/875789/gcc-do-i-need-dreentrant-with-pthreads
Also regarding the lack of a global -pthread in the docs, this post was kind
of illuminating.
http://lists.freebsd.org/pipermail/freebsd-threads/2003-September/001202.html
So the gist of it is, if your only Unix compiler is gcc and if you add
-pthread to your CMAKE_C_FLAGS/CMAKE_CXX_FLAGS you really have no need for
FindThreads at all, as far as I can tell.
--
Philip Lowman
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
