[cmake-developers] CMake 2.8.5-rc3 ready for testing!
The CMake 2.8.5 release candidate stream continues! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D I hope this will be the last release candidate for CMake 2.8.5. We'll build and release 2.8.5 this week unless somebody reports a must fix major regression from a previous release. The pre-built binary builds for the IRIX platform are not yet built and uploaded. I'm having trouble connecting to the build machine for that platform at the moment. As soon as I can connect, I'll get that built and uploaded. Until then, you can build CMake from source on that platform. Following is the list of changes in this release. Since we switched to git, this list is now the 'git log' one line summary written by the named CMake developers. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Happy building! -Dave Changes in CMake 2.8.5-rc3 (since 2.8.5-rc2) Bill Hoffman (4): Use devenv instead of msbuild for vs2010. Revert With very long file names, VS 2010 was unable to compile files. Use relative paths for custom command inputs. Look for VCExpress as a possible build tool as well as devenv. Brad King (3): KWSys: Recognize color TERM=screen-256color-bce (#12287) find_library: Use lib-lib64 conversion in CXX-only projects (#12247,#12248) libarchive: Install COPYING with CMake documentation Christoph Höger (1): FindJNI: Search in Fedora arch-specific JVM location (#12276) Julien Malik (1): FindSWIG: Use NAMES in find_program directives (#12280) Modestas Vainius (1): Documentation: Fix spelling / formatting errors (#12287) Philip Lowman (3): FindBoost: Fixes #12188 FindBoost: Also search for 1.46.1 Detect VS 2010 SP1, faster and more robust detection ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Dependency on library in a separate branch
On 06/27/2011 12:43 AM, Klaim - Joël Lamotte wrote:
2011/6/26 David Cole david.c...@kitware.com
In your top level CMakeLists.txt:
add_subdirectory(B)
add_subdirectory(A)
add_subdirectory(C)
A C must come after B since they both depend on B.
Does that help?
Thanks for your answer. It don't seem so, but let me explain you the full
context:
in the root directory I have
add_subdirectory( tools )
in the tools directory i have
add_subdirectory(B)
add_subdirectory(A)
I suppose I already thought that there was some kind of order in dependency
declaration, so it looks like the same you tell me, but to be complete:
In directory A I have the CMakeLists.txt file to define the executable A, no
add_subdirectory().
In directory B I have the CMakeLists.txt file to define the library B, with
add_subdirectory(C)
So it seems that your suggestion don't work but the difference remains in
the tree structure so I'm not sure what is impacted.
Maybe I did something wrong somewhere else.
The full repostory is up to date now there:
http://code.google.com/p/art-of-sequence/source/browse/
In tools directory, project A is aosdesigner, project B is aoslcpp, project
C is the test project under aoslcpp.
I feel really dumb, I'm sure it's obvious but can't find why it don't work
with aosdesigner project that now requires aoslcpp
With the directory structure
/myrepo/tools/aosdesigner
/myrepo/tools/aoslcpp
/myrepo/tools/aoslcpp/test
aosdesigner must be informed about aoslcpp's include directory because
it is not inherited by aosdesigner as it is inherited by aoslcpp/test
since the latter is entered after aoslcpp issued INCLUDE_DIRECTORIES().
Include directories have directory scope whereas regular targets are
global, so you can refer to aoslcpp from aosdesigner's CMakeLists.txt
although the aoslcpp target has been defined in a sibling directory
next to aosdesigner's one, but the same does not work for include
directories. In aosdesigner's CMakeLists.txt, you should use
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/tools/aoslcpp/include)
or
INCLUDE_DIRECTORIES(../aoslcpp/include)
to make aoslcpp's include directory available for aosdesigner. Note
that if aosdesigner also needs XSD, you should move FIND_PACKAGE(XSD)
to a higher-level CMakeLists.txt file, probably tools/CMakeLists.txt.
'hope that helps.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] XCode4 and archiving
Hey! Thank you for your reply. I tried unsetting CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH but since it is not defined until the generator actually runs it does nothing. An interesting not is that if I do: set(CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH test) all INSTALL_PATH entries in xcode become test, so there should a a connection. The problem lies in that INSTALL_PATH gets set by default to , but a project file generated by XCode does not set it at all. Another bug in the generating step is that this line in cmake: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1,2) generates TARGETED_DEVICE_FAMILY = 1,2; instead of what's correct: TARGETED_DEVICE_FAMILY = 1,2; However, this line: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1) generates: TARGETED_DEVICE_FAMILY = 1; which is correct. Notice the encompassing . So in order to get the encompassing one might try: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1, 2) which generates: TARGETED_DEVICE_FAMILY = 1, 2; However 1, 2 with a space after , can not be parsed by Xcode 4. A hack which works is: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1,2 ) which generates: TARGETED_DEVICE_FAMILY = 1,2 ; which for some reason can be parsed and is parsed correctly by XCode 4. Note the space after 2. Regarding INSTALL_PATH, if someone has any ideas about how this can be fixed using CMake instead of in a script run after the generating step please reply. And another question: Where do I find the code which actually creates the entries in targets of an xcode 4 project? Is it all in the binary or are there any other run-time files which I can modify and perhaps submit as a patch? Johan --- Den sön 2011-06-26 skrev David Cole david.c...@kitware.com: Från: David Cole david.c...@kitware.com Ämne: Re: [CMake] XCode4 and archiving Till: jo...@knutzen.se Kopia: era...@senri.se, cmake@cmake.org Datum: söndag 26 juni 2011 22:37 We will be getting to various Xcode 4 issues over the coming months. In the meantime, I would look into whether there's a way to suppress the generation of the INSTALL_PATH lines rather than having to run a post-processing script. If I remember this later on I'll check into it myself and report back. HTH,David On Sun, Jun 26, 2011 at 12:11 PM, Johan Knutzen knutzen_jo...@yahoo.se wrote: I found a workaround, if anybody is interested. The problem lies in the cmake generator setting the INSTALL_PATH to in the project file. Not sure why cmake does this, but a fix is to remove all entries. Here is a bash script which takes a pbxproj file as argument and fixes it: #! /bin/bash sed -i.bak '/INSTALL_PATH/d' $1 Would be helpful if somebody working on cmake would comment, and perhaps fix this issue. Johan --- Den sön 2011-06-26 skrev Johan Knutzen knutzen_jo...@yahoo.se: Från: Johan Knutzen knutzen_jo...@yahoo.se Ämne: [CMake] XCode4 and archiving Till: cmake@cmake.org Datum: söndag 26 juni 2011 16:00 Hey! I've experienced a few hickups when using cmake with XCode 4, and one of them is the ability to create archives. In the IDE you do this by clicking Product-Archive, which results in an archive which you later can sign with different provisioning profiles when distributing iOS apps to beta testers. However, for projects generated using cmake the archiving command does not work. The result of that command should be an archiving listed in the organizer, but that is not the case when you have a cmake generated project. Does anyone have a solution or work around for this? Johan ___ 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 -Infogad bilaga följer- ___ 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
[CMake] Build order
Hello, I'm using CMake to build OCaml libraries. For that, I use a macro that I call in my CMakeLists.txt As I have dependencies between my different libraries, I wrote my CMakeLists.txt so the build happens in the right order, but when building, libraries are built depending on alphabetical order. add_ocaml_library(cabs SOURCES cabs.ml) add_ocaml_library(algo SOURCES algo.ml) (algo depends on cabs being already built) How can I create a add_ocaml_dependencies macro ? Or is there a way to force CMake to follow the build order in the CMakeLists.txt ? Regards Maxime Lecourt ___ 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] Build order
On 06/27/2011 11:31 AM, Maxime Lecourt wrote: Hello, I'm using CMake to build OCaml libraries. For that, I use a macro that I call in my CMakeLists.txt As I have dependencies between my different libraries, I wrote my CMakeLists.txt so the build happens in the right order, but when building, libraries are built depending on alphabetical order. add_ocaml_library(cabs SOURCES cabs.ml http://cabs.ml) add_ocaml_library(algo SOURCES algo.ml http://algo.ml) (algo depends on cabs being already built) How can I create a add_ocaml_dependencies macro ? Or is there a way to force CMake to follow the build order in the CMakeLists.txt ? Regards Maxime Lecourt Well, if cabs and algo are top-level targets (i.e. created via add_library(), add_executable() or add_custom_target()), you can simply call add_dependencies(algo cabs). Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] [PATCH] add support for component based spec header in RPM generator
Hi,
while making excessive use of the RPM generator in CMake 2.8.5 I came across a
requirement
it could not match out of the box: per-component spec headers.
As it is it seems not to be possible to add to or replace spec-file headers on a
component basis. The Patch below will add this support to CPackRPM.cmake for
CMake 2.8.5.
Headers may be defined by setting CPACK_RPM_COMPONENT_name_header.
-- [snip]--
diff -ru a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
--- a/Modules/CPackRPM.cmake2011-05-25 17:39:24.0 +0200
+++ b/Modules/CPackRPM.cmake2011-06-27 11:32:33.0 +0200
@@ -379,6 +379,28 @@
ENDIF(CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER})
ENDFOREACH(_RPM_SPEC_HEADER)
+# check if additional fields for RPM spec header are given *for this component*
+FOREACH(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX)
+ IF(CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER})
+STRING(LENGTH ${_RPM_SPEC_HEADER} _PACKAGE_HEADER_STRLENGTH)
+MATH(EXPR _PACKAGE_HEADER_STRLENGTH ${_PACKAGE_HEADER_STRLENGTH} - 1)
+STRING(SUBSTRING ${_RPM_SPEC_HEADER} 1 ${_PACKAGE_HEADER_STRLENGTH}
_PACKAGE_HEADER_TAIL)
+STRING(TOLOWER ${_PACKAGE_HEADER_TAIL} _PACKAGE_HEADER_TAIL)
+STRING(SUBSTRING ${_RPM_SPEC_HEADER} 0 1 _PACKAGE_HEADER_NAME)
+SET(_PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME}${_PACKAGE_HEADER_TAIL})
+IF(CPACK_RPM_PACKAGE_DEBUG)
+ MESSAGE(CPackRPM:Debug: User defined ${_PACKAGE_HEADER_NAME} for
${CPACK_RPM_PACKAGE_COMPONENT}:\n
${CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER}})
+ENDIF(CPACK_RPM_PACKAGE_DEBUG)
+IF(TMP_RPM_${_RPM_SPEC_HEADER})
+ SET(TMP_RPM_${_RPM_SPEC_HEADER} ${TMP_RPM_${_RPM_SPEC_HEADER}}
${CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER}})
+ELSE(TMP_RPM_${_RPM_SPEC_HEADER})
+ SET(TMP_RPM_${_RPM_SPEC_HEADER} ${_PACKAGE_HEADER_NAME}:
${CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER}})
+ENDIF(TMP_RPM_${_RPM_SPEC_HEADER})
+ ENDIF(CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER})
+ENDFOREACH(_RPM_SPEC_HEADER)
+
+
+
# CPACK_RPM_SPEC_INSTALL_POST
# May be used to define a RPM post intallation script
# for example setting it to /bin/true may prevent
-- [snip]--
Mit freundlichen Grüßen / Best Regards
René Köcher
Forschung Entwicklung
WINCOR NIXDORF Technology GmbH
Am Vogelherd 67
D - 98693 Ilmenau, Germany
Tel.: +49 (0) 36 77 862-233
Fax:+49 (0) 36 77 862-199
E-Mail: rene.koec...@wincor-nixdorf.com
www.wincor-nixdorf.com
WINCOR NIXDORF Technology GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3523
Geschäftsführer: Eckard Heidloff, Jörn Förster
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE243233085
Diese E-Mail enthält vertrauliche Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
gestattet.
This e-mail may contain confidential information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
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] Build order
2011/6/27 Michael Wild them...@gmail.com On 06/27/2011 11:31 AM, Maxime Lecourt wrote: Hello, I'm using CMake to build OCaml libraries. For that, I use a macro that I call in my CMakeLists.txt As I have dependencies between my different libraries, I wrote my CMakeLists.txt so the build happens in the right order, but when building, libraries are built depending on alphabetical order. add_ocaml_library(cabs SOURCES cabs.ml http://cabs.ml) add_ocaml_library(algo SOURCES algo.ml http://algo.ml) (algo depends on cabs being already built) How can I create a add_ocaml_dependencies macro ? Or is there a way to force CMake to follow the build order in the CMakeLists.txt ? Regards Maxime Lecourt Well, if cabs and algo are top-level targets (i.e. created via add_library(), add_executable() or add_custom_target()), you can simply call add_dependencies(algo cabs). Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake algo and cabs are created using add_custom_command() I tried add_dependencies(algo cabs), but it did not work. Would it work if i create a fake target (can I force cabs and algo as top-level targets, or as valid parameters for add_custom_target ?) ? add_custom_target(target1 depends cabs) add_custom_target(algo depends target1) Or something like that. Maxime Lecourt ___ 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] [PATCH] V2 add support for component based spec header in RPM generator
Small update - TMP_RPM_* fields need to be reset for different components or
they'll add up.
Hi,
while making excessive use of the RPM generator in CMake 2.8.5 I came across
a requirement
it could not match out of the box: per-component spec headers.
As it is it seems not to be possible to add to or replace spec-file headers
on a
component basis. The Patch below will add this support to CPackRPM.cmake for
CMake 2.8.5.
Headers may be defined by setting CPACK_RPM_COMPONENT_name_header.
-- [snip] --
diff -ru a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
--- a/Modules/CPackRPM.cmake2011-05-25 17:39:24.0 +0200
+++ b/Modules/CPackRPM.cmake2011-06-27 12:05:41.0 +0200
@@ -365,6 +365,7 @@
# check if additional fields for RPM spec header are given
FOREACH(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX)
+ SET(TMP_RPM_${_RPM_SPEC_HEADER} )
IF(CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER})
STRING(LENGTH ${_RPM_SPEC_HEADER} _PACKAGE_HEADER_STRLENGTH)
MATH(EXPR _PACKAGE_HEADER_STRLENGTH ${_PACKAGE_HEADER_STRLENGTH} - 1)
@@ -379,6 +380,28 @@
ENDIF(CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER})
ENDFOREACH(_RPM_SPEC_HEADER)
+# check if additional fields for RPM spec header are given *for this component*
+FOREACH(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX)
+ IF(CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER})
+STRING(LENGTH ${_RPM_SPEC_HEADER} _PACKAGE_HEADER_STRLENGTH)
+MATH(EXPR _PACKAGE_HEADER_STRLENGTH ${_PACKAGE_HEADER_STRLENGTH} - 1)
+STRING(SUBSTRING ${_RPM_SPEC_HEADER} 1 ${_PACKAGE_HEADER_STRLENGTH}
_PACKAGE_HEADER_TAIL)
+STRING(TOLOWER ${_PACKAGE_HEADER_TAIL} _PACKAGE_HEADER_TAIL)
+STRING(SUBSTRING ${_RPM_SPEC_HEADER} 0 1 _PACKAGE_HEADER_NAME)
+SET(_PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME}${_PACKAGE_HEADER_TAIL})
+IF(CPACK_RPM_PACKAGE_DEBUG)
+ MESSAGE(CPackRPM:Debug: User defined ${_PACKAGE_HEADER_NAME} for
${CPACK_RPM_PACKAGE_COMPONENT}:\n
${CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER}})
+ENDIF(CPACK_RPM_PACKAGE_DEBUG)
+IF(TMP_RPM_${_RPM_SPEC_HEADER})
+ SET(TMP_RPM_${_RPM_SPEC_HEADER} ${TMP_RPM_${_RPM_SPEC_HEADER}}
${CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER}})
+ELSE(TMP_RPM_${_RPM_SPEC_HEADER})
+ SET(TMP_RPM_${_RPM_SPEC_HEADER} ${_PACKAGE_HEADER_NAME}:
${CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER}})
+ENDIF(TMP_RPM_${_RPM_SPEC_HEADER})
+ ENDIF(CPACK_RPM_COMPONENT_${CPACK_RPM_PACKAGE_COMPONENT}_${_RPM_SPEC_HEADER})
+ENDFOREACH(_RPM_SPEC_HEADER)
+
+
+
# CPACK_RPM_SPEC_INSTALL_POST
# May be used to define a RPM post intallation script
# for example setting it to /bin/true may prevent
-- [snip]--
Mit freundlichen Grüßen / Best Regards
René Köcher
Forschung Entwicklung
WINCOR NIXDORF Technology GmbH
Am Vogelherd 67
D - 98693 Ilmenau, Germany
Tel.: +49 (0) 36 77 862-233
Fax:+49 (0) 36 77 862-199
E-Mail: rene.koec...@wincor-nixdorf.com
www.wincor-nixdorf.com
WINCOR NIXDORF Technology GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3523
Geschäftsführer: Eckard Heidloff, Jörn Förster
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE243233085
Diese E-Mail enthält vertrauliche Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
gestattet.
This e-mail may contain confidential information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
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] [PATCH] V2 add support for component based spec header in RPM generator
[quoting repaired] Hi, while making excessive use of the RPM generator in CMake 2.8.5 I came across a requirement it could not match out of the box: per-component spec headers. As it is it seems not to be possible to add to or replace spec-file headers on a component basis. The Patch below will add this support to CPackRPM.cmake for CMake 2.8.5. Headers may be defined by setting CPACK_RPM_COMPONENT_name_header. Small update - TMP_RPM_* fields need to be reset for different components or they'll add up. Please clone the CMake git and do a local commit of the final version of your patch with a nice changelog. Then do git format-patch -1 and attach the resulting file to a new feature request at http://www.cmake.org/Bug/ Eike ___ 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] XCode4 and archiving
On Mon, Jun 27, 2011 at 4:35 AM, Johan Knutzen knutzen_jo...@yahoo.sewrote: Hey! Thank you for your reply. I tried unsetting CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH but since it is not defined until the generator actually runs it does nothing. An interesting not is that if I do: set(CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH test) all INSTALL_PATH entries in xcode become test, so there should a a connection. The problem lies in that INSTALL_PATH gets set by default to , but a project file generated by XCode does not set it at all. Another bug in the generating step is that this line in cmake: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1,2) generates TARGETED_DEVICE_FAMILY = 1,2; instead of what's correct: TARGETED_DEVICE_FAMILY = 1,2; However, this line: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1) generates: TARGETED_DEVICE_FAMILY = 1; which is correct. Notice the encompassing . So in order to get the encompassing one might try: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1, 2) which generates: TARGETED_DEVICE_FAMILY = 1, 2; However 1, 2 with a space after , can not be parsed by Xcode 4. A hack which works is: set(CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY 1,2 ) which generates: TARGETED_DEVICE_FAMILY = 1,2 ; which for some reason can be parsed and is parsed correctly by XCode 4. Note the space after 2. Regarding INSTALL_PATH, if someone has any ideas about how this can be fixed using CMake instead of in a script run after the generating step please reply. And another question: Where do I find the code which actually creates the entries in targets of an xcode 4 project? Is it all in the binary or are there any other run-time files which I can modify and perhaps submit as a patch? It's in the source code for CMake itself, likely in one or more of these files: $ find . | grep -i xcode | grep -v /.git/ ./Modules/CMakeFindXCode.cmake ./Source/cmGlobalXCodeGenerator.cxx ./Source/cmGlobalXCodeGenerator.h ./Source/cmLocalXCodeGenerator.cxx ./Source/cmLocalXCodeGenerator.h ./Source/cmXCode21Object.cxx ./Source/cmXCode21Object.h ./Source/cmXCodeObject.cxx ./Source/cmXCodeObject.h Johan --- Den *sön 2011-06-26 skrev David Cole david.c...@kitware.com*: Från: David Cole david.c...@kitware.com Ämne: Re: [CMake] XCode4 and archiving Till: jo...@knutzen.se Kopia: era...@senri.se, cmake@cmake.org Datum: söndag 26 juni 2011 22:37 We will be getting to various Xcode 4 issues over the coming months. In the meantime, I would look into whether there's a way to suppress the generation of the INSTALL_PATH lines rather than having to run a post-processing script. If I remember this later on I'll check into it myself and report back. HTH, David On Sun, Jun 26, 2011 at 12:11 PM, Johan Knutzen knutzen_jo...@yahoo.sehttp://mc/compose?to=knutzen_jo...@yahoo.se wrote: I found a workaround, if anybody is interested. The problem lies in the cmake generator setting the INSTALL_PATH to in the project file. Not sure why cmake does this, but a fix is to remove all entries. Here is a bash script which takes a pbxproj file as argument and fixes it: #! /bin/bash sed -i.bak '/INSTALL_PATH/d' $1 Would be helpful if somebody working on cmake would comment, and perhaps fix this issue. Johan --- Den sön 2011-06-26 skrev Johan Knutzen knutzen_jo...@yahoo.sehttp://mc/compose?to=knutzen_jo...@yahoo.se : Från: Johan Knutzen knutzen_jo...@yahoo.sehttp://mc/compose?to=knutzen_jo...@yahoo.se Ämne: [CMake] XCode4 and archiving Till: cmake@cmake.org http://mc/compose?to=cmake@cmake.org Datum: söndag 26 juni 2011 16:00 Hey! I've experienced a few hickups when using cmake with XCode 4, and one of them is the ability to create archives. In the IDE you do this by clicking Product-Archive, which results in an archive which you later can sign with different provisioning profiles when distributing iOS apps to beta testers. However, for projects generated using cmake the archiving command does not work. The result of that command should be an archiving listed in the organizer, but that is not the case when you have a cmake generated project. Does anyone have a solution or work around for this? Johan ___ 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:
Re: [CMake] [PATCH] V2 add support for component based spec header in RPM generator
Hi, Hi, while making excessive use of the RPM generator in CMake 2.8.5 I came across a requirement it could not match out of the box: per-component spec headers. As it is it seems not to be possible to add to or replace spec-file headers on a component basis. The Patch below will add this support to CPackRPM.cmake for CMake 2.8.5. Headers may be defined by setting CPACK_RPM_COMPONENT_name_header. Small update - TMP_RPM_* fields need to be reset for different components or they'll add up. Please clone the CMake git and do a local commit of the final version of your patch with a nice changelog. Then do git format-patch -1 and attach the resulting file to a new feature request at http://www.cmake.org/Bug/ Sure, I'll do that - thanks. Is there an official guide for the process? I was only able to finde the cmake-list on the kitware homepage but maybe I wasn't looking hard enough. Eike Rene WINCOR NIXDORF Technology GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3523 Geschäftsführer: Eckard Heidloff, Jörn Förster Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE243233085 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ 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] [PATCH] V2 add support for component based spec header in RPM generator
2011/6/27 Koecher, Rene rene.koec...@wincor-nixdorf.com: Hi, Hi, while making excessive use of the RPM generator in CMake 2.8.5 I came across a requirement it could not match out of the box: per-component spec headers. As it is it seems not to be possible to add to or replace spec-file headers on a component basis. The Patch below will add this support to CPackRPM.cmake for CMake 2.8.5. Headers may be defined by setting CPACK_RPM_COMPONENT_name_header. Small update - TMP_RPM_* fields need to be reset for different components or they'll add up. Please clone the CMake git and do a local commit of the final version of your patch with a nice changelog. Then do git format-patch -1 and attach the resulting file to a new feature request at http://www.cmake.org/Bug/ Sure, I'll do that - thanks. Is there an official guide for the process? I was only able to finde the cmake-list on the kitware homepage but maybe I wasn't looking hard enough. Not really written anywhere but that would be nice page to add to the wiki. That said Eike is perfectly right with the process: 1) format patch 2) create a feature request / bug report on http://www.cmake.org/Bug/ Usually 0) would be to check the bug tracker for any already existing entry regarding the issue and/or try with CMake git master branch in order to be up-to-date. You already did that.by using 2.8.5 current rc. -- 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] Build order
On 06/27/2011 12:00 PM, Maxime Lecourt wrote: 2011/6/27 Michael Wild them...@gmail.com mailto:them...@gmail.com On 06/27/2011 11:31 AM, Maxime Lecourt wrote: Hello, I'm using CMake to build OCaml libraries. For that, I use a macro that I call in my CMakeLists.txt As I have dependencies between my different libraries, I wrote my CMakeLists.txt so the build happens in the right order, but when building, libraries are built depending on alphabetical order. add_ocaml_library(cabs SOURCES cabs.ml http://cabs.ml http://cabs.ml) add_ocaml_library(algo SOURCES algo.ml http://algo.ml http://algo.ml) (algo depends on cabs being already built) How can I create a add_ocaml_dependencies macro ? Or is there a way to force CMake to follow the build order in the CMakeLists.txt ? Regards Maxime Lecourt Well, if cabs and algo are top-level targets (i.e. created via add_library(), add_executable() or add_custom_target()), you can simply call add_dependencies(algo cabs). Michael algo and cabs are created using add_custom_command() I tried add_dependencies(algo cabs), but it did not work. Would it work if i create a fake target (can I force cabs and algo as top-level targets, or as valid parameters for add_custom_target ?) ? add_custom_target(target1 depends cabs) add_custom_target(algo depends target1) Or something like that. Maxime Lecourt Yes, you should create a custom target with add_custom_target(). In CMake you have to distinguish between top-level and file-level targets. add_custom_command() only creates a file-level target, so you need the add_custom_target() call. Also, this will make it possible to build the targets selectively from the command line or the IDE. However, your above shown code is semantically wrong. Your add_ocaml_library() macro (you probably should make it a function instead) should contain the add_custom_target() call and give it the name passed to the add_ocaml_library function. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What is the VS10 .rule file generated for each ADD_CUSTOM_COMMAND?
On 6/25/2011 11:40 AM, Gabriel Petrovay wrote:
(Using Cmake 2.8.4)
I think this was something I just fixed. There were some cases where
the rule files were not be created. If you could post a small example I
could take a look and see if it is fixed now.
Also, please try the most current RC for 2.8.5.
-Bill
On Sat, Jun 25, 2011 at 5:39 PM, Gabriel Petrovay
gabipetro...@gmail.com mailto:gabipetro...@gmail.com wrote:
Hi,
1. What is the rule file?
2. What is the logic by which this file is generated?
I have a list of src files that need to be generated, each by an
ADD_CUSTOM_COMMAND
in a FOREACH loop:
FOREACH(SRC ${SRC_LIST})
// no code here
ADD_CUSTOM_COMMAND(...)
// no code here
ENDFOREACH(SRC)
And all BUT the first generated SRC files get a SRC.rule file in
the same build directory? Why this?
Moreover, if I look in the vcxproj file generated I see that the
CustomBuild is slightly different for the first SRC in the list.
The first CustomBuild elements (for the 1st item in SRC_LIST) has
as Include attribute the relative path (from the current build
dir) to the MAIN_DEPENDENCY.
The rest CustomBuild elements (for the rest items in SRC_LIST)
have as Include attribute the relative path (from the current
build dir) to the SRC.rule file.
Why is this?
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034 tel:%2B41%280%29787978034
www.28msec.com http://www.28msec.com
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com http://www.28msec.com
___
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
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
___
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] Appending to the LINK_FLAGS target property ?
For variables like CMAKE_C_FLAGS one can append to them like this:
set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)
For target properties like LINK_FLAGS I was using this command:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/NODEFAULTLIB:LIBCMT)
to do the append. However, when I append a second time:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/INCLUDE:_InitLibrary)
then it breaks because the string that Visual Studio sees contains a
semicolon in between the 2 options. I can work round this by writing my
append like this:
get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS)
set(link_flags ${link_flags} /INCLUDE:_InitLibrary)
set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags})
but that is a bit verbose for my liking. I understand that the semicolons
are how cmake separates list items from one another but shouldn't cmake
automatically stringify the list (by replacing semicolons with spaces)
before passing it through to the generator code ? The same problem will
occur for any of the XXX_FLAGS properties like COMPILE_FLAGS that are passed
through unchanged to the makefile or Visual Studio project file.
Is it worth filing a feature request to ask for cmake to stringify lists for
the appropriate variables ? Or is there a good reason why cmake can't or
shouldn't implement this behaviour ?
--
Glenn
___
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] CMake 2.8.5-rc3 ready for testing!
The CMake 2.8.5 release candidate stream continues! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D I hope this will be the last release candidate for CMake 2.8.5. We'll build and release 2.8.5 this week unless somebody reports a must fix major regression from a previous release. The pre-built binary builds for the IRIX platform are not yet built and uploaded. I'm having trouble connecting to the build machine for that platform at the moment. As soon as I can connect, I'll get that built and uploaded. Until then, you can build CMake from source on that platform. Following is the list of changes in this release. Since we switched to git, this list is now the 'git log' one line summary written by the named CMake developers. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Happy building! -Dave Changes in CMake 2.8.5-rc3 (since 2.8.5-rc2) Bill Hoffman (4): Use devenv instead of msbuild for vs2010. Revert With very long file names, VS 2010 was unable to compile files. Use relative paths for custom command inputs. Look for VCExpress as a possible build tool as well as devenv. Brad King (3): KWSys: Recognize color TERM=screen-256color-bce (#12287) find_library: Use lib-lib64 conversion in CXX-only projects (#12247,#12248) libarchive: Install COPYING with CMake documentation Christoph Höger (1): FindJNI: Search in Fedora arch-specific JVM location (#12276) Julien Malik (1): FindSWIG: Use NAMES in find_program directives (#12280) Modestas Vainius (1): Documentation: Fix spelling / formatting errors (#12287) Philip Lowman (3): FindBoost: Fixes #12188 FindBoost: Also search for 1.46.1 Detect VS 2010 SP1, faster and more robust detection ___ 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] Enabling C99 in CMake
On Jun 24, 2011, at 11:30 PM, Michael Hertling wrote: On 06/23/2011 06:20 PM, Jed Brown wrote: On Thu, Jun 23, 2011 at 17:50, Michael Hertling mhertl...@online.de wrote: You need to use a C99 compiler for your project This is already a problem. C99 introduces new keywords (e.g. restrict) and removes implicit int. It is entirely possible for part of a project to include C89-conforming legacy code that is not valid C99. The use of C99 or C89 should be a file- and directory-level property. That's a really good point and could indeed be very well addressed by a possibility for a project to enable language dialects per directory/ target/file as Todd has asked for in his initial posting. Yep -- After reading all the responses, think my suggestion was insufficient. Just having a variable for the compiler flags isn't enough. Also, I really like the dialects approach here. This has the potential to take care of not only C99, but also C++ *and* Fortran. The Fortran support in CMake could really use this kind of thing, as it would be very helpful to know if particular Fortran compilers support F90, F77, F08, etc. In order to achieve this in a platform/compiler-independent manner, take a look at the attached dialects.patch file, a diff against the Modules directory of CMake 2.8.4. It is not meant as a production-ready solution, but as as proof of concept, and it's restricted to the GNU C compiler, though it should be easily applicable to the other compilers known by CMake. Thanks for making this! First of all, the new Compiler/LanguageDialects.cmake file provides a function __language_dialects() which accepts a language and a paired list of arguments denoting each supported language dialect followed by the flags to enable it. The function sets up the variable CMAKE_LANG_ DIALECTS_INIT containing the list of dialects, and for each dialect a variable CMAKE_LANG_DIALECT_DIALECT_INIT containing the respective flags. The Compiler/GNU-C.cmake file is enhanced to - exemplary - call __language_dialects(C C90 -std=c90 C89 -std=c89 C99 -std=c99 C9X -std=c9x C1X -std=c1x ANSI -ansi) This looks great. One question is what to do with things like gnu99. This is C99 plus GNU extensions. I ask because the GNU compiler separates this from regular C99, while other compilers like XL don't. If you run xlc -qlanglvl=c99, it supports inline assembly, but if you run gcc -std=c99, it does not. You have to run with std=gnu99. I *suspect* that most people will prefer gnu99 by default, as the lenient mode is the default for both gcc and xlc, but I could be conjecturing too far here. My suggestion would be to have an option like CMAKE_STRICT_C_DIALECT=TRUE that says to also turn off support for compiler-specific extensions if possible, e.g.: gcc:-std=c99 xlc:-qnoasm -qlanglvl=c99 and stick to the standard, but prefer the more lenient mode by default e.g.: gcc:-std=gnu99 xlc:-qlanglvl=c99 This turns out to be a simple and promising approach that - provides the developers with platform/compiler-independent variables to check if the compiler accepts a certain dialect and to enable it, Yes. This is great. - places the compiler-specific dialect flags in the compiler-specific files in the Modules/Compiler directory where they obviously belong, Excellent. - doesn't require complicated modifications in the Modules directory. Also great. If you like this idea, feel free to add it to the feature request Todd has filed in the meantime. However, while this approach is independent of the dialects a compiler actually supports, be aware that mixed C89/ C90 projects to be built with CMake need *one* compiler which masters C89 *and* C99, and that's not guaranteed for all of them. I'm not sure what a good way around this would be, given the current internals of CMake. I would personally like to see CMake support multiple compilers like this for other reasons (mixing cross-compiled and non-cross-compiled builds) but I don't think that will happen in the near future and I'm not sure what a clean way to support it would be. It's also horrible to encumber the poor user just trying to build your project with needing to know whether it is written in C99 or whatever else, nor with how to make their compiler deliver that dialect. Once the CMake-detected or user-specified compiler isn't suitable for the project, the user is in charge of choosing another one, and this might happen quite quickly; it's sufficient that the compiler is not in the PATH or unusually named. Then, the user must know whether the project needs a C and/or C++ and/or Fortran compiler, and where it's located. In such a situation, the need to know that a C99 compiler is required does not make any further difference to the user, IMO. This seems in line with the current level of knowledge effort required to build a
Re: [CMake] Enabling C99 in CMake
On Jun 26, 2011, at 7:12 AM, Owen Shepherd wrote: On 25/06/2011 07:30, Michael Hertling mhertl...@online.de wrote: On 06/24/2011 04:16 PM, Owen Shepherd wrote: I think the appropriate solution here is a project-specific dialect flag - perhaps one taking options in the GNU format since it seems most familiar. One could perhaps generalise this further - a file-specific dialect flag which defaults to the value of the project-specific flag If there are individual compilers for C89/C99, and a projects needs a C99 one, any dialect flags - project/directory/target/file specific - would be of no use, wouldn't they? Rather, one must specify the C99 compiler if it isn't found automatically by CMake during the initial configuration, and the project might consider to check the compiler's C99 capabilities. Sorry - I should have said property rather than flag. That is, something along the lines of set_target_properties(the_target PROPERTIES C_DIALECT C99) Or set_source_files_properties(myfile.c PROPERTIES C_DIALECT C99) (I'm not entirely sure here whether the source file property should be C_DIALECT or just DIALECT. The language, after all, should be unambiguous at this point) It would then be the responsibility of the Cmake machinery to choose the right compiler and set it up for building code with the given dialect. I *think* Michael's concern here is that if you have a project that uses C99, it should fail as fast as possible, e.g. when it knows that the detected/provided compiler does not support C99 as it processes the 'project' command at the beginning of the CMakeLists.txt file. I think it would be acceptable if things failed later than that. e.g., you could have: project(foo C CXX) Suppose a C89-only compiler is detected. The build now knows that's the only dialect it supports. It should fail when it sees this later: set_target_properties(the_target PROPERTIES C_DIALECT C99) If, however, there is a C99 file that does NOT have such a property set on it, I don't think there is anything you can do about that. Here, the build would just fail when it tries to compile that file. I think the right behavior is to keep the current behavior for files/targets/projects that do not have dialect properties set on them. -Todd -- Owen Shepherd http://www.owenshepherd.net owen.sheph...@e43.eu (general) / oshephe...@shef.ac.uk (academic) ___ 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 __ Todd Gamblin, tgamb...@llnl.gov, http://people.llnl.gov/gamblin2 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA ___ 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] Enabling C99 in CMake
Michael Hertling wrote:
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C89})
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c99.c
PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C99})
ADD_LIBRARY(c89 c89.c)
ADD_LIBRARY(c99 c99.c)
It issues the supported C dialects and the contents of the associated
dialect variables, and the c89.c and c99.c source files are compiled
with the correct flags. Of course, the CMAKE_C_DIALECT_DIALECT
variables can also be appended to the CMAKE_C_FLAGS[_CONFIG]
variables instead of the COMPILE_FLAGS source file property.
With a bit of thinking I would suggest a slightly different way. Don't add
specific compiler flags for that source file. Tell CMake that this sourcefile
uses
a specific language dialect:
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
PROPERTIES LANGUAGE_DIALECT C89)
Then let CMake internally do the fiddling with the compile flags. This would
have a few benefits:
-if e.g. the language flags need to be passed first to the compiler CMake can
assure this
-colliding flags can be detected by the underlying implementation
-if we ever get support for e.g. 2 different C compilers things like the Sun
(was it Sun? Too lazy to look up) compilers can be supported as CMake would
just call the right compiler binary
-this can easily change in any direction later if someone decides the
underlying implementation needs a change
Well, basically all points target in the same direction, no? It seperates the
switch logic from the user and allow greater flexibility in the implementation.
With the expense that probably some C++ code of CMake needs to be touched.
Eike
signature.asc
Description: This is a digitally signed message part.
___
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] CTest and Git submodules
Hi,
currently I use the following to update git submodules during the ctest:
if (EXISTS ${CTEST_SOURCE_DIRECTORY}/.gitmodules)
execute_process (COMMAND ${GIT_EXECUTABLE} submodule init
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
# Update the sub modules
execute_process (COMMAND ${GIT_EXECUTABLE} submodule update
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
endif ()
The problem here is that if a submodule has also submodules this doesnt
work, so I tried it with:
if (EXISTS ${CTEST_SOURCE_DIRECTORY}/.gitmodules)
execute_process (COMMAND ${GIT_EXECUTABLE} submodule init
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
# Update the sub modules
execute_process (COMMAND ${GIT_EXECUTABLE} submodule update
--recursive
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
endif ()
The main problem here is that the submodule init command doesnt
initialize recursive.
Now, the question I want to ask is, if there is something in CMake/CTest
which I can call or if someone has already solved this problem.
Many thanks in advance
Best Regards
NoRulez
___
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] What is the VS10 .rule file generated for each ADD_CUSTOM_COMMAND?
On 6/27/2011 11:57 AM, Gabriel Petrovay wrote: Hi Bill, I have no exception. I only know that Cmake generates a wrong Include attribute for a CustomBuild element (first in a series of cmake generated filed). This generated file also does not have a .rule file generated for it like for all the others in the loop. If you could provide a small example that shows this issue, it would be very helpful in fixing this for you. Where exactly is 2.8.5? See Dave Cole's email to the cmake mailing list about 2.8.5 RC 3. http://www.cmake.org/cmake/resources/software.html I will also give it a try with 2.8.5 once I have it. In the meanwhile can you also please give me some details about the rule files? Thanks! 1. What is the rule file? 2. What is the logic by which this file is generated? The custom commands in VS require that they are hung on a file. It is not sufficient to list inputs and outputs and create a rule. With VS 7, 8, and 9, the .rule file did not need to exist. VS 2010 does not run rules that hang off of non-existent files. So, we have to actually create the files... -Bill ___ 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] [CMake ] Specify linker for a mixed language Fortran/C++ application (linux)
Hello,
I ran into some trouble trying to link a mixed language Fortran/C++
program.
I used a CMakeLists.txt that looks about like this:
# cmake version
cmake_minimum_required(VERSION 2.8)
# name of the project
PROJECT(Q2P1)
enable_language (Fortran)
set(CMAKE_Fortran_COMPILER mpif90)
# add subdirectories
ADD_SUBDIRECTORY(CPLUSPLUS)
SET(src_fortran ...)
ADD_EXECUTABLE(Q2P1 ${src_fortran})
target_link_libraries(Q2P1 CPLUSPLUSLibrary)
I invoke cmake like this CC=mpicc CXX=mpic++ cmake
-DCMAKE_Fortran_COMPILER=mpif90
and a working Makefile is produced, the code compiles with no error and
the CPLUSPLUSLibrary is created.
The linking process exits with an error /usr/lib/../lib64/crt1.o: In
function `_start':
/usr/src/packages/BUILD/glibc-2.9/csu/../sysdeps/x86_64/elf/start.S:109:
undefined reference to `main'
This happens because mpic++ is used to link, but the main program is
actually in the Fortran code. So the linking command looks about like
this mpic++ (list of object files) -o executable
The problem is solved when I just manually copy and paste the link
command that is printed on the command line and replace mpic++ with
mpif90... So the question is how can I tell
cmake to use mpif90 to link the program? I tried setting CMAKE_LINKER to
mpif90, but that did not change anything...
Thanks,
Raphael
___
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 Git submodules
If anyone is interessted, I think I found a solution:
git submodule update --init --recursive
Instead of both lines
Best Regards
Am 27.06.2011 um 19:56 schrieb NoRulez noru...@me.com:
Hi,
currently I use the following to update git submodules during the ctest:
if (EXISTS ${CTEST_SOURCE_DIRECTORY}/.gitmodules)
execute_process (COMMAND ${GIT_EXECUTABLE} submodule init
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
# Update the sub modules
execute_process (COMMAND ${GIT_EXECUTABLE} submodule update
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
endif ()
The problem here is that if a submodule has also submodules this doesn’t
work, so I tried it with:
if (EXISTS ${CTEST_SOURCE_DIRECTORY}/.gitmodules)
execute_process (COMMAND ${GIT_EXECUTABLE} submodule init
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
# Update the sub modules
execute_process (COMMAND ${GIT_EXECUTABLE} submodule update
--recursive
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
endif ()
The main problem here is that the “submodule init” command doesn’t initialize
“recursive”.
Now, the question I want to ask is, if there is something in CMake/CTest
which I can call or if someone has already solved this problem.
Many thanks in advance
Best Regards
NoRulez
___
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 ] Specify linker for a mixed language Fortran/C++ application (linux)
On 06/27/2011 02:39 PM, Raphael Münster wrote: enable_language (Fortran) set(CMAKE_Fortran_COMPILER mpif90) Set the compiler variable *before* enabling the language. The enable_language command does a whole bunch of introspection of the compiler. -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] depend.mk doesn't include /usr/local headers
I've just spent several hours chasing down a problem that was related to cmake makefiles not detecting a change in a header in /usr/local. I would build a new version of a library, run 'make install' which would put it into /usr/local, then rebuild my project. I mistakenly assumed that if one of the headers that was installed had changed then my code would be recompiled. Is there a way to ask CMake to add dependencies to files in /usr/local or files under a specific directory automatically? Thanks, James ___ 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] Enabling C99 in CMake
Am Montag, 27. Juni 2011, 18:40:19 schrieb Todd Gamblin: On Jun 26, 2011, at 7:12 AM, Owen Shepherd wrote: On 25/06/2011 07:30, Michael Hertling mhertl...@online.de wrote: On 06/24/2011 04:16 PM, Owen Shepherd wrote: I think the appropriate solution here is a project-specific dialect flag - perhaps one taking options in the GNU format since it seems most familiar. One could perhaps generalise this further - a file-specific dialect flag which defaults to the value of the project-specific flag If there are individual compilers for C89/C99, and a projects needs a C99 one, any dialect flags - project/directory/target/file specific - would be of no use, wouldn't they? Rather, one must specify the C99 compiler if it isn't found automatically by CMake during the initial configuration, and the project might consider to check the compiler's C99 capabilities. Sorry - I should have said property rather than flag. That is, something along the lines of set_target_properties(the_target PROPERTIES C_DIALECT C99) Or set_source_files_properties(myfile.c PROPERTIES C_DIALECT C99) (I'm not entirely sure here whether the source file property should be C_DIALECT or just DIALECT. The language, after all, should be unambiguous at this point) It would then be the responsibility of the Cmake machinery to choose the right compiler and set it up for building code with the given dialect. I *think* Michael's concern here is that if you have a project that uses C99, it should fail as fast as possible, e.g. when it knows that the detected/provided compiler does not support C99 as it processes the 'project' command at the beginning of the CMakeLists.txt file. Please keep in mind that porjects might use _some_ but not all aspects of C99 because they want to support a compiler like MSVC which is not fully C99 compatible. What do you want to do with those? Also the project might have adding header files (e.g. unofficial versions of inttypes.h and stdint.h for MSVC) to allow usage of C99 although the plain compiler does not support that. HS ___ 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] Enabling C99 in CMake
On Jun 27, 2011, at 10:26 PM, Hendrik Sattler wrote: Am Montag, 27. Juni 2011, 18:40:19 schrieb Todd Gamblin: I *think* Michael's concern here is that if you have a project that uses C99, it should fail as fast as possible, e.g. when it knows that the detected/provided compiler does not support C99 as it processes the 'project' command at the beginning of the CMakeLists.txt file. Please keep in mind that porjects might use _some_ but not all aspects of C99 because they want to support a compiler like MSVC which is not fully C99 compatible. What do you want to do with those? Also the project might have adding header files (e.g. unofficial versions of inttypes.h and stdint.h for MSVC) to allow usage of C99 although the plain compiler does not support that. I think, that if the compiler only offers some support for C99, then that should be the default when you request C99, as that is the best you can do... Wouldn't that take care of this situation? -Todd __ Todd Gamblin, tgamb...@llnl.gov, http://people.llnl.gov/gamblin2 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA ___ 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-commits] CMake branch, release, updated. v2.8.4-611-g73c1280
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, release has been updated via 73c12803e6c672ba5c441d2049ef22cfbc12873e (commit) via 8d7884c84a6071a282a61c992e41391834788d51 (commit) via ea1a519a356cb8b6a54ca3858f20aa9560be9ccf (commit) via 11b4eb2b8a506b4d697375175883dcb1a8323002 (commit) via 428cfb8dcbdd22379970e9f07334ed59342587a9 (commit) via 4ccf44bcb2ab5bbacb172790f0fa55cba13522a0 (commit) via 26607e9ae32ab8e62a94cbf9b93f8653a3a7756a (commit) via 8555c2b4b768037a37705ef7f2486149ae3cdc13 (commit) via 672b6ca5e431f511f2638511b0128b6956f3e3ad (commit) via ed0075bdb768f8272c2a9fc48e37bf9897427258 (commit) via d0d5540dc6593ea635050738be9073e40a1eabde (commit) via 38368d52f34086294f4647b97a7111fa2547905a (commit) via 8cd66dc0d275208367dd6b5ef266395ef92ed424 (commit) from e8e1048c5ff7b625af32cee6a3072e8d979d2033 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=73c12803e6c672ba5c441d2049ef22cfbc12873e commit 73c12803e6c672ba5c441d2049ef22cfbc12873e Author: David Cole david.c...@kitware.com AuthorDate: Mon Jun 27 06:59:58 2011 -0400 Commit: David Cole david.c...@kitware.com CommitDate: Mon Jun 27 06:59:58 2011 -0400 CMake 2.8.5-rc3 include regression fix diff --git a/ChangeLog.manual b/ChangeLog.manual index e9694f4..02a4307 100644 --- a/ChangeLog.manual +++ b/ChangeLog.manual @@ -1,5 +1,11 @@ Changes in CMake 2.8.5-rc3 (since 2.8.5-rc2) +Bill Hoffman (4): + Use devenv instead of msbuild for vs2010. + Revert With very long file names, VS 2010 was unable to compile files. + Use relative paths for custom command inputs. + Look for VCExpress as a possible build tool as well as devenv. + Brad King (3): KWSys: Recognize color TERM=screen-256color-bce (#12287) find_library: Use lib-lib64 conversion in CXX-only projects (#12247,#12248) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d7884c84a6071a282a61c992e41391834788d51 commit 8d7884c84a6071a282a61c992e41391834788d51 Merge: ea1a519 e8e1048 Author: David Cole david.c...@kitware.com AuthorDate: Mon Jun 27 06:56:42 2011 -0400 Commit: David Cole david.c...@kitware.com CommitDate: Mon Jun 27 06:56:42 2011 -0400 Merge branch 'release' --- Summary of changes: ChangeLog.manual |6 + Modules/CMakeVS10FindMake.cmake| 29 +++ Source/cmGlobalVisualStudio10Generator.cxx |3 +- Source/cmVisualStudio10TargetGenerator.cxx | 16 ++- Source/kwsys/kwsysDateStamp.cmake |2 +- 5 files changed, 44 insertions(+), 12 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.4-1830-ga15f323
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via a15f3235f5f912894d641b26a430509dc102b196 (commit) via ea1a519a356cb8b6a54ca3858f20aa9560be9ccf (commit) via 11b4eb2b8a506b4d697375175883dcb1a8323002 (commit) via 428cfb8dcbdd22379970e9f07334ed59342587a9 (commit) from 54ad90e47600e5f597f3b20590ba1359486e8c98 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a15f3235f5f912894d641b26a430509dc102b196 commit a15f3235f5f912894d641b26a430509dc102b196 Merge: 54ad90e ea1a519 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jun 27 12:50:12 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Jun 27 12:50:12 2011 -0400 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.4-1832-g8cf4d72
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 8cf4d72d0d49b9456e23d66212e06280fbe89543 (commit)
via 2377d7a2cfa58a3f78775fc417396c5099e98de1 (commit)
from a15f3235f5f912894d641b26a430509dc102b196 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8cf4d72d0d49b9456e23d66212e06280fbe89543
commit 8cf4d72d0d49b9456e23d66212e06280fbe89543
Merge: a15f323 2377d7a
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jun 27 13:02:52 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jun 27 13:02:52 2011 -0400
Merge topic 'revert-fixbug_0004147' into next
2377d7a Revert Add a new function SWIG_GET_WRAPPER_DEPENDENCIES to
UseSWIG.cmake
diff --cc Modules/UseSWIG.cmake
index be15b52,b547dc7..2a83045
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@@ -220,14 -166,8 +165,10 @@@ MACRO(SWIG_ADD_SOURCE_TO_MODULE name ou
IF(SWIG_MODULE_${name}_EXTRA_FLAGS)
SET(swig_extra_flags ${swig_extra_flags}
${SWIG_MODULE_${name}_EXTRA_FLAGS})
ENDIF(SWIG_MODULE_${name}_EXTRA_FLAGS)
- SWIG_GET_WRAPPER_DEPENDENCIES(${swig_source_file_fullname}
- ${swig_generated_file_fullname}
${SWIG_MODULE_${name}_SWIG_LANGUAGE_FLAG}
- swig_extra_dependencies)
- LIST(APPEND SWIG_MODULE_${name}_EXTRA_DEPS ${swig_extra_dependencies})
ADD_CUSTOM_COMMAND(
OUTPUT ${swig_generated_file_fullname} ${swig_extra_generated_files}
+# Let's create the ${swig_outdir} at execution time, in case dir contains
$(OutDir)
+COMMAND ${CMAKE_COMMAND} -E make_directory ${swig_outdir}
COMMAND ${SWIG_EXECUTABLE}
ARGS -${SWIG_MODULE_${name}_SWIG_LANGUAGE_FLAG}
${swig_source_file_flags}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2377d7a2cfa58a3f78775fc417396c5099e98de1
commit 2377d7a2cfa58a3f78775fc417396c5099e98de1
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jun 27 12:51:05 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jun 27 12:51:05 2011 -0400
Revert Add a new function SWIG_GET_WRAPPER_DEPENDENCIES to UseSWIG.cmake
This reverts commit 1088b0278e74526298d0821589973918da33c44b.
The fix for issue #4147 introduced issue #12307. Revert to original
behavior until a solution is found.
diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index f9808c5..b547dc7 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -4,9 +4,6 @@
# - Define swig module with given name and specified language
# SWIG_LINK_LIBRARIES(name [ libraries ])
# - Link libraries to swig module
-# SWIG_GET_WRAPPER_DEPENDENCIES(swigFile genWrapper language DEST_VARIABLE)
-# - Put dependencies of the wrapper genWrapper generated by swig from
-# swigFile in DEST_VARIABLE
# All other macros are for internal use only.
# To get the actual name of the swig module,
# use: ${SWIG_MODULE_${name}_REAL_NAME}.
@@ -42,58 +39,6 @@ SET(SWIG_EXTRA_LIBRARIES )
SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION py)
#
-# Get dependencies of the generated wrapper.
-#
-MACRO(SWIG_GET_WRAPPER_DEPENDENCIES swigFile genWrapper language DEST_VARIABLE)
- GET_FILENAME_COMPONENT(swig_getdeps_basename ${swigFile} NAME_WE)
- GET_FILENAME_COMPONENT(swig_getdeps_outdir ${genWrapper} PATH)
- GET_SOURCE_FILE_PROPERTY(swig_getdeps_extra_flags ${swigFile} SWIG_FLAGS)
- IF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
-SET(swig_getdeps_extra_flags )
- ENDIF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
-
- IF(NOT swig_getdeps_outdir)
-SET(swig_getdeps_outdir ${CMAKE_CURRENT_BINARY_DIR})
- ENDIF(NOT swig_getdeps_outdir)
- SET(swig_getdeps_depsfile
-${swig_getdeps_outdir}/swig_${swig_getdeps_basename}_deps.txt)
- GET_DIRECTORY_PROPERTY(swig_getdeps_include_directories INCLUDE_DIRECTORIES)
- SET(swig_getdeps_include_dirs)
- FOREACH(it ${swig_getdeps_include_directories})
-SET(swig_getdeps_include_dirs ${swig_getdeps_include_dirs} -I${it})
- ENDFOREACH(it)
- EXECUTE_PROCESS(
-COMMAND ${SWIG_EXECUTABLE}
--MM -MF ${swig_getdeps_depsfile} ${swig_getdeps_extra_flags}
-${CMAKE_SWIG_FLAGS} -${language}
--o ${genWrapper} ${swig_getdeps_include_dirs} ${swigFile}
-RESULT_VARIABLE swig_getdeps_result
-ERROR_VARIABLE swig_getdeps_error
-OUTPUT_STRIP_TRAILING_WHITESPACE)
- IF(NOT ${swig_getdeps_error} EQUAL 0)
-MESSAGE(SEND_ERROR Command \${SWIG_EXECUTABLE} -MM -MF
${swig_getdeps_depsfile} ${swig_getdeps_extra_flags} ${CMAKE_SWIG_FLAGS}
-${language} -o ${genWrapper} ${swig_getdeps_include_dirs} ${swigFile}\ failed
with output:\n${swig_getdeps_error})
-
[Cmake-commits] CMake branch, next, updated. v2.8.4-1834-g4024a1a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4024a1ac7c1730046181fc4c1de892ddfffe8f83 (commit)
via fc045318f846b66c0db94e25ab64658064107014 (commit)
from 8cf4d72d0d49b9456e23d66212e06280fbe89543 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4024a1ac7c1730046181fc4c1de892ddfffe8f83
commit 4024a1ac7c1730046181fc4c1de892ddfffe8f83
Merge: 8cf4d72 fc04531
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jun 27 13:39:48 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jun 27 13:39:48 2011 -0400
Merge topic 'revert-fixbug_0004147' into next
fc04531 Revert Add a new function SWIG_GET_WRAPPER_DEPENDENCIES to
UseSWIG.cmake
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc045318f846b66c0db94e25ab64658064107014
commit fc045318f846b66c0db94e25ab64658064107014
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jun 27 12:51:05 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jun 27 13:36:01 2011 -0400
Revert Add a new function SWIG_GET_WRAPPER_DEPENDENCIES to UseSWIG.cmake
This reverts commit 1088b0278e74526298d0821589973918da33c44b.
Wrapper dependency scanning (fix for #4147) does not work at CMake
configuration time if an input file is provided by a custom command
(regression #12307). Revert to original behavior until a solution is
found.
diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index f9808c5..b547dc7 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -4,9 +4,6 @@
# - Define swig module with given name and specified language
# SWIG_LINK_LIBRARIES(name [ libraries ])
# - Link libraries to swig module
-# SWIG_GET_WRAPPER_DEPENDENCIES(swigFile genWrapper language DEST_VARIABLE)
-# - Put dependencies of the wrapper genWrapper generated by swig from
-# swigFile in DEST_VARIABLE
# All other macros are for internal use only.
# To get the actual name of the swig module,
# use: ${SWIG_MODULE_${name}_REAL_NAME}.
@@ -42,58 +39,6 @@ SET(SWIG_EXTRA_LIBRARIES )
SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION py)
#
-# Get dependencies of the generated wrapper.
-#
-MACRO(SWIG_GET_WRAPPER_DEPENDENCIES swigFile genWrapper language DEST_VARIABLE)
- GET_FILENAME_COMPONENT(swig_getdeps_basename ${swigFile} NAME_WE)
- GET_FILENAME_COMPONENT(swig_getdeps_outdir ${genWrapper} PATH)
- GET_SOURCE_FILE_PROPERTY(swig_getdeps_extra_flags ${swigFile} SWIG_FLAGS)
- IF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
-SET(swig_getdeps_extra_flags )
- ENDIF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
-
- IF(NOT swig_getdeps_outdir)
-SET(swig_getdeps_outdir ${CMAKE_CURRENT_BINARY_DIR})
- ENDIF(NOT swig_getdeps_outdir)
- SET(swig_getdeps_depsfile
-${swig_getdeps_outdir}/swig_${swig_getdeps_basename}_deps.txt)
- GET_DIRECTORY_PROPERTY(swig_getdeps_include_directories INCLUDE_DIRECTORIES)
- SET(swig_getdeps_include_dirs)
- FOREACH(it ${swig_getdeps_include_directories})
-SET(swig_getdeps_include_dirs ${swig_getdeps_include_dirs} -I${it})
- ENDFOREACH(it)
- EXECUTE_PROCESS(
-COMMAND ${SWIG_EXECUTABLE}
--MM -MF ${swig_getdeps_depsfile} ${swig_getdeps_extra_flags}
-${CMAKE_SWIG_FLAGS} -${language}
--o ${genWrapper} ${swig_getdeps_include_dirs} ${swigFile}
-RESULT_VARIABLE swig_getdeps_result
-ERROR_VARIABLE swig_getdeps_error
-OUTPUT_STRIP_TRAILING_WHITESPACE)
- IF(NOT ${swig_getdeps_error} EQUAL 0)
-MESSAGE(SEND_ERROR Command \${SWIG_EXECUTABLE} -MM -MF
${swig_getdeps_depsfile} ${swig_getdeps_extra_flags} ${CMAKE_SWIG_FLAGS}
-${language} -o ${genWrapper} ${swig_getdeps_include_dirs} ${swigFile}\ failed
with output:\n${swig_getdeps_error})
-SET(swig_getdeps_dependencies )
- ELSE(NOT ${swig_getdeps_error} EQUAL 0)
-FILE(READ ${swig_getdeps_depsfile} ${DEST_VARIABLE})
-# Remove the first line
-STRING(REGEX REPLACE ^.+: +\n +
- ${DEST_VARIABLE} ${${DEST_VARIABLE}})
-# Clean the end of each line
-STRING(REGEX REPLACE +()?\n \n ${DEST_VARIABLE}
- ${${DEST_VARIABLE}})
-# Clean beginning of each line
-STRING(REGEX REPLACE \n + \n
- ${DEST_VARIABLE} ${${DEST_VARIABLE}})
-# clean paths
-STRING(REGEX REPLACE / ${DEST_VARIABLE}
- ${${DEST_VARIABLE}})
-STRING(REGEX REPLACE \n ;
- ${DEST_VARIABLE} ${${DEST_VARIABLE}})
- ENDIF(NOT ${swig_getdeps_error} EQUAL 0)
-ENDMACRO(SWIG_GET_WRAPPER_DEPENDENCIES)
-
-
-#
# For given swig module initialize variables associated with it
#
MACRO(SWIG_MODULE_INITIALIZE name language)
@@
[Cmake-commits] CMake branch, master, updated. v2.8.4-605-g34238d5
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 34238d5bcb92c7c9a2652126de2001ec4c73a4c9 (commit) from ea1a519a356cb8b6a54ca3858f20aa9560be9ccf (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=34238d5bcb92c7c9a2652126de2001ec4c73a4c9 commit 34238d5bcb92c7c9a2652126de2001ec4c73a4c9 Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue Jun 28 00:01:03 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue Jun 28 00:13:12 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 3463dff..bbbd0fa 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 06) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 27) +SET(KWSYS_DATE_STAMP_DAY 28) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
