Re: [CMake] Cmake 2.8.2 Bug under windows
Hi, can you please check if this may related also to this BUG: http://cmake.org/Bug/view.php?id=11153 It happens on Windows only at a root dir. Thanks, Claus On 16.08.2010, at 15:31, Brad King wrote: On 08/13/2010 06:03 PM, J Decker wrote: Yes, this patch fixes the problem thank you. Thanks for testing it. I've committed upstream. -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] Creating custom file before building/compiling with cmake
So, how must the file "ApplicationVersion.xml.in" looks like? I didn't find the documentation for the *.in file extensions.Thanks in advanceBest RegardsNoRulezAm 21. Aug 2010 um 02:08 schrieb Michael Hertling mhertl...@online.de:On 08/20/2010 12:42 PM, Michael Wild wrote:
On 19. Aug, 2010, at 23:36 , Michael Hertling wrote:
On 08/19/2010 09:42 PM, Michael Wild wrote:
In that case I recommend creating a CMake script (e.g. create_application_version.cmake) which creates the ApplicationVersion.xml file. It queries the current revision (have a look at FindSVN.cmake on how to do this), determines the date and time (this is a problem, refer to this thread for more info: http://www.mail-archive.com/cmake@cmake.org/msg30662.html) and then either does a configure_file() or a file(WRITE) to create ApplicationVersion.xml. Ideally the create_application_version.cmake is also a configured file (with the path to the build and source tree and the path to the svn executable etc.).
This script is then invoked by a custom command:
# dummy_file is never created...
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/ApplicationVersion.xml ${CMAKE_BINARY_DIR}/dummy_file
COMMAND ${CMAKE_EXECUTABLE} -P ${CMAKE_BINARY_DIR}/create_application_version.cmake
COMMENT "Creating ApplicationVersion.xml"
VERBATIM
)
# this intentionally depends on dummy_file, which is never created
add_custom_target(create_appplication_version ALL
DEPENDS ${CMAKE_BINARY_DIR}/ApplicationVersion.xml ${CMAKE_BINARY_DIR}/dummy_file)
add_executable(super_duper main.cpp ${CMAKE_BINARY_DIR}/ApplicationVersion.xml)
add_dependencies(super_duper create_appplication_version)
The trick I'm trying to pull off, is that super_duper depends on create_appplication_version, which is always out of date and depends on the non-existing file dummy_file, thus always updating ApplicationVersion.xml. Not that I haven't tested this.
Possibly, this may be simplified: The COMMAND can be transferred from
the custom command to the custom target, so the former goes away and
one doesn't need a dummy file for triggering. Furthermore, the custom
target doesn't need to be declared ALL, and the ApplicationVersion.xml
doesn't need to appear in ADD_EXECUTABLE(), but as it's no header and,
thus, not subject to CMake's dependency scanning, one has to imply an
explicit dependency through the OBJECT_DEPENDS source file property on
main.cpp to ensure the executable's rebuild when ApplicationVersion.xml
changes.
Ahh, I forgot about the OBJECT_DEPENDS. And you also need to set the GENERATED property to TRUE on the ApplicationVersion.xml file if you leave away the custom command, otherwise CMake will complain at configure time. But all-in-all probably simpler, and you don't need the despicable dummy_file.
Yes, the GENERATED property should be set, but if there's a template
named ApplicationVersion.xml.in CMake won't complain about a missing
ApplicationVersion.xml not marked as GENERATED since it checks for a
".in" extension automatically.
The create_application_version.cmake should use CONFIGURE_FILE() to
generate the ApplicationVersion.xml since this function doesn't write
a new output file if it wouldn't differ from the previous one, so the
ApplicationVersion.xml doesn't trigger rebuilds if it doesn't actually
change. At http://www.cmake.org/pipermail/cmake/2010-July/037958.htmlgt;
and http://www.cmake.org/pipermail/cmake/2010-July/038015.htmlgt;, you'll
find a similar discussion.
If he's going to encode the time that probably won't matter, since the file will most likely always differ...
Yes, and I assume it's not the OP's desire to trigger a rebuild because
of a hand's leap. ;) Hence, what should be done is to generate one file
with the version and another file with the timestamp, preferably by the
same custom target, but to impose a dependency on the version file only.
So, the version and the timestamp are regenerated each time a concerned
target is checked for being up to date, but solely a new version will
trigger a rebuild.
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
___
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] Creating custom file before building/compiling with cmake
The .in suffix is merely a convention. Refer to the documentation of the
configure_file command for more info.
Michael
On 21.08.2010, at 11:04, Roman Wüger noru...@me.com@mac.com wrote:
So, how must the file ApplicationVersion.xml.in looks like? I didn't find
the documentation for the *.in file extensions.
Thanks in advance
Best Regards
NoRulez
Am 21. Aug 2010 um 02:08 schrieb Michael Hertling mhertl...@online.de:
On 08/20/2010 12:42 PM, Michael Wild wrote:
On 19. Aug, 2010, at 23:36 , Michael Hertling wrote:
On 08/19/2010 09:42 PM, Michael Wild wrote:
In that case I recommend creating a CMake script (e.g.
create_application_version.cmake) which creates the
ApplicationVersion.xml file. It queries the current revision (have a
look at FindSVN.cmake on how to do this), determines the date and time
(this is a problem, refer to this thread for more info:
http://www.mail-archive.com/cmake@cmake.org/msg30662.html) and then
either does a configure_file() or a file(WRITE) to create
ApplicationVersion.xml. Ideally the create_application_version.cmake is
also a configured file (with the path to the build and source tree and
the path to the svn executable etc.).
This script is then invoked by a custom command:
# dummy_file is never created...
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/ApplicationVersion.xml
${CMAKE_BINARY_DIR}/dummy_file
COMMAND ${CMAKE_EXECUTABLE} -P
${CMAKE_BINARY_DIR}/create_application_version.cmake
COMMENT Creating ApplicationVersion.xml
VERBATIM
)
# this intentionally depends on dummy_file, which is never created
add_custom_target(create_appplication_version ALL
DEPENDS ${CMAKE_BINARY_DIR}/ApplicationVersion.xml
${CMAKE_BINARY_DIR}/dummy_file)
add_executable(super_duper main.cpp
${CMAKE_BINARY_DIR}/ApplicationVersion.xml)
add_dependencies(super_duper create_appplication_version)
The trick I'm trying to pull off, is that super_duper depends on
create_appplication_version, which is always out of date and depends on
the non-existing file dummy_file, thus always updating
ApplicationVersion.xml. Not that I haven't tested this.
Possibly, this may be simplified: The COMMAND can be transferred from
the custom command to the custom target, so the former goes away and
one doesn't need a dummy file for triggering. Furthermore, the custom
target doesn't need to be declared ALL, and the ApplicationVersion.xml
doesn't need to appear in ADD_EXECUTABLE(), but as it's no header and,
thus, not subject to CMake's dependency scanning, one has to imply an
explicit dependency through the OBJECT_DEPENDS source file property on
main.cpp to ensure the executable's rebuild when ApplicationVersion.xml
changes.
Ahh, I forgot about the OBJECT_DEPENDS. And you also need to set the
GENERATED property to TRUE on the ApplicationVersion.xml file if you leave
away the custom command, otherwise CMake will complain at configure time.
But all-in-all probably simpler, and you don't need the despicable
dummy_file.
Yes, the GENERATED property should be set, but if there's a template
named ApplicationVersion.xml.in CMake won't complain about a missing
ApplicationVersion.xml not marked as GENERATED since it checks for a
.in extension automatically.
The create_application_version.cmake should use CONFIGURE_FILE() to
generate the ApplicationVersion.xml since this function doesn't write
a new output file if it wouldn't differ from the previous one, so the
ApplicationVersion.xml doesn't trigger rebuilds if it doesn't actually
change. At http://www.cmake.org/pipermail/cmake/2010-July/037958.htmlgt;
and http://www.cmake.org/pipermail/cmake/2010-July/038015.htmlgt;,
you'll
find a similar discussion.
If he's going to encode the time that probably won't matter, since the
file will most likely always differ...
Yes, and I assume it's not the OP's desire to trigger a rebuild because
of a hand's leap. ;) Hence, what should be done is to generate one file
with the version and another file with the timestamp, preferably by the
same custom target, but to impose a dependency on the version file only.
So, the version and the timestamp are regenerated each time a concerned
target is checked for being up to date, but solely a new version will
trigger a rebuild.
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
___
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
[CMake] Support for multiple components in cpack (reloaded)
Hi All, I finally rebased my previous work on component support for Archive Generators (i.e. STGZ TBZ2 TGZ TZZIP) (see also ML discussions: http://www.cmake.org/pipermail/cmake/2010-July/038575.html http://www.cmake.org/pipermail/cmake/2010-August/038663.html http://www.cmake.org/pipermail/cmake-developers/2010-August/000413.html) Up-to-date patches may be retrieved from http://public.kitware.com/Bug/view.php?id=10736 or pulled from http://github.com/TheErk/CMake/tree/CPackArchiveGenerator-ComponentSupport (beware of the fact that this branch has been rebased so do not try to update re-pull it from scratch) I think this work may now be merged in CMake upstream but I need some final testing. The implemented features are the following: 1) ALL archive generators (STGZ TBZ2 TGZ TZZIP) are now supporting component install 2) The default behavior is to generate 1 package for each COMPONENT GROUP (see http://paraview.org/Wiki/CMake:Component_Install_With_CPack#Grouping_Components) 3) 3 new CPACK_COMPONENTS var have been introduced: CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE CPACK_COMPONENTS_IGNORE_GROUPS All those vars may be set at CPack time e.g: cpack -D CPACK_COMPONENTS_IGNORE_GROUPS=1 -G ZIP They change the number and the contents of the generated packages: 3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all components GROUPS 3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all COMPONENTS 3.c) CPACK_COMPONENTS_IGNORE_GROUPS means you want to get 1 package per COMPONENT (the default is 1 package per GROUP) The difference between 3.a) and 3.b) m CPACK_COMPONENTS_ALL -- 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] Support for multiple components in cpack (reloaded)
2010/8/21 Eric Noulard eric.noul...@gmail.com: [...] They change the number and the contents of the generated packages: 3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all components GROUPS 3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all COMPONENTS 3.c) CPACK_COMPONENTS_IGNORE_GROUPS means you want to get 1 package per COMPONENT (the default is 1 package per GROUP) argh push ENTER too fast... The difference between 3.a) and 3.b) may not be obvious but one should know that COMPONENT install will install components which are specified in CPACK_COMPONENTS_ALL (component which are not specified there won't be installed at all in any case) BUT some component may NOT BELONG TO ANY GROUP. In this case 3.b will include the orphan component whereas 3.a will NOT. last but not least there exist a special component automatically generated by CPack the component is named Unspecified and contains all INSTALLed file/targets/... which do not specify COMPONENT. If Unspecified is contained in CPACK_COMPONENTS_ALL then again 3.b will include the Unspecified component whereas 3.a will NOT. 3.c should always include ALL COMPONENTS specified in CPACK_COMPONENTS_ALL. Note that there is existing feature of CPack which would just make CPack ignore the component stuff this is CPACK_MONOLITHIC_INSTALL. The CPACK_MONOLITHIC_INSTALL has a different objective because: * CPACK_MONOLITHIC_INSTALL is used AT CMake time whereas 3.a, 3.b and 3.c may be used AT CPack time. Thus if you use CPACK_MONOLITHIC_INSTALL all the CPack time component stuff will be ignored. * One other difference is the fact that CPack time component control variable may let you package only a chosen portion of the INSTALLed things CPACK_MONOLITHIC_INSTALL cannot do that. Any feedback on this stuff is welcomed. After that I will go on for RPM and DEB component support which will be similar but may be more difficult because it has to support inter-component dependencies which is just not handled at all for Archive Generators. -- 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] [Insight-users] CMake 2.8.0 problem
I've tried to configure InsightToolkit-3.16.0 using CMake 2.8.0 and I'm using Visual c++ 2008 Express Edition. what I did, I just select source file(InsightToolkit-3.16.0) and binary file and I've got the following message: Check for working C compiler: cl CMake Error: Remove failed on file: D:/ITK 18/vc2008/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe: System Error: Permission denied Check for working C compiler: cl -- broken CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:50 (MESSAGE): The C compiler cl is not able to compile a simple test program. It fails with the following output: Change Dir: D:/ITK 18/vc2008/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~1\MICROS~1.0\Common7\IDE\VCExpress.exe CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec Microsoft (R) Visual C++ Express Edition Version 9.0.30729.1. Copyright (C) Microsoft Corp 2007. All rights reserved. -- Build started: Project: cmTryCompileExec, Configuration: Debug Win32 -- Compiling... Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. cl /Od /D WIN32 /D _WINDOWS /D _DEBUG /D CMAKE_INTDIR=\Debug\ /D _MBCS /FD /RTC1 /MDd /FocmTryCompileExec.dir\Debug\\ /FdD:/ITK 18/vc2008/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb /W3 /c /Zi /TC /Zm1000 .\testCCompiler.c testCCompiler.c Compiling manifest to resources... Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 Copyright (C) Microsoft Corporation. All rights reserved. Linking... LINK : fatal error LNK1105: cannot close file 'D:\ITK 18\vc2008\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe' Build log was saved at file://d:\ITK 18\vc2008\CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug\BuildLog.htm cmTryCompileExec - 1 error(s), 0 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:8 (PROJECT) Configuring incomplete, errors occurred! I hope to solve this problem, Thanks in advance. I would first upgrade to cmake-2.8.2. There were a few bugs in 2.8.0 that were fixed months ago with 2.8.2. After that I would check if you have write permissions on d:\itk. But wait a minute, did you set the build folder to be d:\Itk with the source to be the same location. Its much better to not have the build folder and source folder on the same tree. So for example if your source is in D:\ITK put your build tree in d:\Build\ITK John ___ 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] Creating custom file before building/compiling with cmake
OK, I added "CONFIGURE_FILE(xml/ApplicationVersion.xml.in xml/ApplicationVersion.xml)" to the CMakeLists.txt file which builds the main.cppThe file "xml/ApplicationVersion.xml.in" looks like the following:?xml version="1.0" encoding="UTF-8"?ApplicationVersion Date${BUILD_DATE}/Date Time${BUILD_TIME}/Time Architecture${BUILD_ARCHITECTURE}/Architecture Version Major${BUILD_VERSION_MAJOR}/Major Minor${BUILD_VERSION_MINOR}/Minor Patch${BUILD_VERSION_PATCH}/Patch Build${BUILD_VERSION_BUILD}/Build Revision${BUILD_VERSION_REVISION}/Revision /Version/ApplicationVersionBut when I run mingw32-make, then no "xml/ApplicationVersion.xml" file is created.Is there something else I must do to get it working? How can I get right that the "xml/ApplicationVersion.xml" file is UTF-8 encoded?Best RegardsNoRulezAm 21. Aug 2010 um 13:04 schrieb Michael Wild them...@gmail.com:The .in suffix is merely a convention. Refer to the documentation of the configure_file command for more info.MichaelOn 21.08.2010, at 11:04, "Roman Wüger" noru...@mecom@mac.com wrote:So, how must the file "ApplicationVersion.xml.in" looks like? I didn't find the documentation for the *.in file extensions.Thanks in advanceBest RegardsNoRulezAm 21. Aug 2010 um 02:08 schrieb Michael Hertling mhertl...@online.de:On 08/20/2010 12:42 PM, Michael Wild wrote:
On 19. Aug, 2010, at 23:36 , Michael Hertling wrote:
On 08/19/2010 09:42 PM, Michael Wild wrote:
In that case I recommend creating a CMake script (e.g. create_application_version.cmake) which creates the ApplicationVersion.xml file. It queries the current revision (have a look at FindSVN.cmake on how to do this), determines the date and time (this is a problem, refer to this thread for more info: http://www.mail-archive.com/cmake@cmake.org/msg30662.html) and then either does a configure_file() or a file(WRITE) to create ApplicationVersion.xml. Ideally the create_application_version.cmake is also a configured file (with the path to the build and source tree and the path to the svn executable etc.).
This script is then invoked by a custom command:
# dummy_file is never created...
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/ApplicationVersion.xml ${CMAKE_BINARY_DIR}/dummy_file
COMMAND ${CMAKE_EXECUTABLE} -P ${CMAKE_BINARY_DIR}/create_application_version.cmake
COMMENT "Creating ApplicationVersion.xml"
VERBATIM
)
# this intentionally depends on dummy_file, which is never created
add_custom_target(create_appplication_version ALL
DEPENDS ${CMAKE_BINARY_DIR}/ApplicationVersion.xml ${CMAKE_BINARY_DIR}/dummy_file)
add_executable(super_duper main.cpp ${CMAKE_BINARY_DIR}/ApplicationVersion.xml)
add_dependencies(super_duper create_appplication_version)
The trick I'm trying to pull off, is that super_duper depends on create_appplication_version, which is always out of date and depends on the non-existing file dummy_file, thus always updating ApplicationVersion.xml. Not that I haven't tested this.
Possibly, this may be simplified: The COMMAND can be transferred from
the custom command to the custom target, so the former goes away and
one doesn't need a dummy file for triggering. Furthermore, the custom
target doesn't need to be declared ALL, and the ApplicationVersion.xml
doesn't need to appear in ADD_EXECUTABLE(), but as it's no header and,
thus, not subject to CMake's dependency scanning, one has to imply an
explicit dependency through the OBJECT_DEPENDS source file property on
maincpp to ensure the executable's rebuild when ApplicationVersion.xml
changes.
Ahh, I forgot about the OBJECT_DEPENDS. And you also need to set the GENERATED property to TRUE on the ApplicationVersion.xml file if you leave away the custom command, otherwise CMake will complain at configure time. But all-in-all probably simpler, and you don't need the despicable dummy_file.
Yes, the GENERATED property should be set, but if there's a template
named ApplicationVersion.xml.in CMake won't complain about a missing
ApplicationVersion.xml not marked as GENERATED since it checks for a
".in" extension automatically.
The create_application_version.cmake should use CONFIGURE_FILE() to
generate the ApplicationVersion.xml since this function doesn't write
a new output file if it wouldn't differ from the previous one, so the
ApplicationVersion.xml doesn't trigger rebuilds if it doesn't actually
change. At http://www.cmake.org/pipermail/cmake/2010-July/037958.htmlgt;
and http://www.cmake.org/pipermail/cmake/2010-July/038015.htmlgt;, you'll
find a similar discussion.
If he's going to encode the time that probably won't matter, since the file will most likely always differ...
Yes, and I assume it's not the OP's desire to trigger a rebuild because
of a hand's leap. ;) Hence, what should be done is to generate one file
with the version and another file with the timestamp, preferably by the
same custom target, but to impose a dependency on the version file only.
So, the version and the timestamp are
Re: [CMake] Creating custom file before building/compiling with cmake
After trying a bit around, the following will work:SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/src/main.cpp PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/xml/ApplicationVersion.xml)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/xml/ApplicationVersion.xml PROPERTIES GENERATED TRUE)
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/xml/ApplicationVersion.xml.in ${CMAKE_CURRENT_SOURCE_DIR}/xml/ApplicationVersion.xml)
ADD_CUSTOM_TARGET(ApplicationVersion ALL DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/xml/ApplicationVersion.xml)
ADD_EXECUTABLE(super_duper )TARGET_LINK_LIBRARIES(super_duper )ADD_DEPENDENCIES(super_duper ApplicationVersion)Is this the correct way?Best RegardsNoRulezAm 21. Aug 2010 um 16:48 schrieb "Roman Wüger" noru...@me.com@mac.com:OK, I added "CONFIGURE_FILE(xml/ApplicationVersion.xml.in xml/ApplicationVersion.xml)" to the CMakeLists.txt file which builds the main.cppThe file "xml/ApplicationVersion.xml.in" looks like the following:?xml version="1.0" encoding="UTF-8"?ApplicationVersion Date${BUILD_DATE}/Date Time${BUILD_TIME}/Time Architecture${BUILD_ARCHITECTURE}/Architecture Version Major${BUILD_VERSION_MAJOR}/Major Minor${BUILD_VERSION_MINOR}/Minor Patch${BUILD_VERSION_PATCH}/Patch Build${BUILD_VERSION_BUILD}/Build Revision${BUILD_VERSION_REVISION}/Revision /Version/ApplicationVersionBut when I run mingw32-make, then no "xml/ApplicationVersion.xml" file is created.Is there something else I must do to get it working? How can I get right that the "xml/ApplicationVersion.xml" file is UTF-8 encoded?Best RegardsNoRulezAm 21. Aug 2010 um 13:04 schrieb Michael Wild them...@gmail.com:The .in suffix is merely a convention. Refer to the documentation of the configure_file command for more info.MichaelOn 21.08.2010, at 11:04, "Roman Wüger" noru...@mecom@mac.com wrote:So, how must the file "ApplicationVersion.xml.in" looks like? I didn't find the documentation for the *.in file extensions.Thanks in advanceBest RegardsNoRulezAm 21. Aug 2010 um 02:08 schrieb Michael Hertling mhertl...@online.de:On 08/20/2010 12:42 PM, Michael Wild wrote:
On 19. Aug, 2010, at 23:36 , Michael Hertling wrote:
On 08/19/2010 09:42 PM, Michael Wild wrote:
In that case I recommend creating a CMake script (e.g. create_application_version.cmake) which creates the ApplicationVersion.xml file. It queries the current revision (have a look at FindSVN.cmake on how to do this), determines the date and time (this is a problem, refer to this thread for more info: http://www.mail-archive.com/cmake@cmake.org/msg30662.html) and then either does a configure_file() or a file(WRITE) to create ApplicationVersion.xml. Ideally the create_application_version.cmake is also a configured file (with the path to the build and source tree and the path to the svn executable etc.).
This script is then invoked by a custom command:
# dummy_file is never created...
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/ApplicationVersion.xml ${CMAKE_BINARY_DIR}/dummy_file
COMMAND ${CMAKE_EXECUTABLE} -P ${CMAKE_BINARY_DIR}/create_application_version.cmake
COMMENT "Creating ApplicationVersion.xml"
VERBATIM
)
# this intentionally depends on dummy_file, which is never created
add_custom_target(create_appplication_version ALL
DEPENDS ${CMAKE_BINARY_DIR}/ApplicationVersion.xml ${CMAKE_BINARY_DIR}/dummy_file)
add_executable(super_duper main.cpp ${CMAKE_BINARY_DIR}/ApplicationVersion.xml)
add_dependencies(super_duper create_appplication_version)
The trick I'm trying to pull off, is that super_duper depends on create_appplication_version, which is always out of date and depends on the non-existing file dummy_file, thus always updating ApplicationVersion.xml. Not that I haven't tested this.
Possibly, this may be simplified: The COMMAND can be transferred from
the custom command to the custom target, so the former goes away and
one doesn't need a dummy file for triggering. Furthermore, the custom
target doesn't need to be declared ALL, and the ApplicationVersion.xml
doesn't need to appear in ADD_EXECUTABLE(), but as it's no header and,
thus, not subject to CMake's dependency scanning, one has to imply an
explicit dependency through the OBJECT_DEPENDS source file property on
maincpp to ensure the executable's rebuild when ApplicationVersion.xml
changes.
Ahh, I forgot about the OBJECT_DEPENDS. And you also need to set the GENERATED property to TRUE on the ApplicationVersion.xml file if you leave away the custom command, otherwise CMake will complain at configure time. But all-in-all probably simpler, and you don't need the despicable dummy_file.
Yes, the GENERATED property should be set, but if there's a template
named ApplicationVersion.xml.in CMake won't complain about a missing
ApplicationVersion.xml not marked as GENERATED since it checks for a
".in" extension automatically.
The create_application_version.cmake should use CONFIGURE_FILE() to
generate the ApplicationVersion.xml since this function
Re: [CMake] Creating custom file before building/compiling with cmake
On 21. Aug, 2010, at 16:48 , Roman Wüger @mac.com wrote:
OK,
I added CONFIGURE_FILE(xml/ApplicationVersion.xml.in
xml/ApplicationVersion.xml) to the CMakeLists.txt file which builds the
main.cpp
The file xml/ApplicationVersion.xml.in looks like the following:
?xml version=1.0 encoding=UTF-8?
ApplicationVersion
Date${BUILD_DATE}/Date
Time${BUILD_TIME}/Time
Architecture${BUILD_ARCHITECTURE}/Architecture
Version
Major${BUILD_VERSION_MAJOR}/Major
Minor${BUILD_VERSION_MINOR}/Minor
Patch${BUILD_VERSION_PATCH}/Patch
Build${BUILD_VERSION_BUILD}/Build
Revision${BUILD_VERSION_REVISION}/Revision
/Version
/ApplicationVersion
But when I run mingw32-make, then no xml/ApplicationVersion.xml file is
created.
Is there something else I must do to get it working? How can I get right that
the xml/ApplicationVersion.xml file is UTF-8 encoded?
Best Regards
NoRulez
That won't work, you're missing all the parts I was telling you about in my
original instructions. You need a script (call it e.g.
createApplicationVersion.cmake.in) containing something like this:
createApplicationVersion.cmake.in:
--8--
# configured variables
set(WIN32 @WIN32@)
set(UNIX @UNIX@)
set(SVN_EXECUTABLE @Subversion_SVN_EXECUTABLE@)
set(CMAKE_SOURCE_DIR @CMAKE_SOURCE_DIR@)
set(CMAKE_BINARY_DIR @CMAKE_BINARY_DIR@)
# make sure we don't get translated messages
set(ENV{LC_ALL} C)
# determine date
if(WIN32)
execute_process(COMMAND cmd /c date /T
RESULT_VARIABLE getdate_result
OUTPUT_VARIABLE DATE
ERROR_VARIABLE DATE
OUTPUT_STRIP_TRAILING_WHITESPACE)
string(REGEX REPLACE .*(..)/(..)/()
\\3-\\1-\\2 DATE ${DATE})
elseif(UNIX)
execute_process(COMMAND date +%Y-%m-%d
RESULT_VARIABLE getdate_result
OUTPUT_VARIABLE DATE
ERROR_VARIABLE DATE
OUTPUT_STRIP_TRAILING_WHITESPACE)
else()
message(FATAL_ERROR Can't determine date on this system.)
endif()
if(getdate_result)
message(FATAL_ERROR Failed to determine date:\n${DATE})
endif()
# determine SVN revision
execute_process(COMMAND ${SVN_EXECUTABLE} info ${CMAKE_SOURCE_DIR}
RESULT_VARIABLE svn_info_result
OUTPUT_VARIABLE SVN_REVISION
ERROR_VARIABLE SVN_REVISION
OUTPUT_STRIP_TRAILING_WHITESPACE)
if(svn_info_result)
message(FATAL_ERROR Failed to determine SVN revision:\n${SVN_REVISION})
endif()
string(REGEX REPLACE ^(.*\n)?Revision: ([^\n]+).*
\\2 SVN_REVISION ${SVN_REVISION})
# create the ApplicationVersion.xml file
configure_file(${CMAKE_SOURCE_DIR}/ApplicationVersion.xml.in
${CMAKE_BINARY_DIR}/ApplicationVersion.xml @ONLY)
--8--
And in your CMakeLists.txt you do the following:
CMakeLists.txt:
---8--
# ...
find_package(Subversion REQUIRED)
configure_file(createApplicationVersion.cmake.in
${CMAKE_BINARY_DIR}/createApplicationVersion.cmake
@ONLY)
add_custom_target(create_ApplicationVersion
COMMAND ${CMAKE_COMMAND} -P
${CMAKE_BINARY_DIR}/createApplicationVersion.cmake
COMMENT Creating ${CMAKE_BINARY_DIR}/ApplicationVersion.xml)
add_executable(super_duper main.cpp
${CMAKE_BINARY_DIR}/ApplicationVersion.xml)
add_dependencies(super_duper create_ApplicationVersion)
set_source_files_properties(main.cpp PROPERTIES
OBJECT_DEPENDS ${CMAKE_BINARY_DIR}/ApplicationVersion.xml)
set_source_files_properties(${CMAKE_BINARY_DIR}/ApplicationVersion.xml
PROPERTIES
GENERATED TRUE)
# ...
---8--
Note that I haven't tested this code, but I hope it gets you started.
Michael
Am 21. Aug 2010 um 13:04 schrieb Michael Wild them...@gmail.com:
The .in suffix is merely a convention. Refer to the documentation of the
configure_file command for more info.
Michael
On 21.08.2010, at 11:04, Roman Wüger noru...@me.com@mac.com wrote:
So, how must the file ApplicationVersion.xml.in looks like? I didn't find
the documentation for the *.in file extensions.
Thanks in advance
Best Regards
NoRulez
Am 21. Aug 2010 um 02:08 schrieb Michael Hertling mhertl...@online.de:
On 08/20/2010 12:42 PM, Michael Wild wrote:
On 19. Aug, 2010, at 23:36 , Michael Hertling wrote:
On 08/19/2010 09:42 PM, Michael Wild wrote:
In that case I recommend creating a CMake script (e.g.
create_application_version.cmake) which creates the
ApplicationVersion.xml file. It queries the current revision (have a
look at FindSVN.cmake on how to do this), determines the date and time
(this is a problem, refer to this thread for more info:
http://www.mail-archive.com/cmake@cmake.org/msg30662.html) and then
either does a configure_file() or a file(WRITE) to create
ApplicationVersion.xml. Ideally the create_application_version.cmake
is also a configured file (with the path to the build and source tree
and the path to the svn executable etc.).
This script is then invoked by a custom command:
# dummy_file is never created...
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/ApplicationVersion.xml
Re: [CMake] Problem with CTest and configuration specific binary paths
On 08/20/2010 09:44 PM, Iman Brouwer wrote:
Hello,
The path to a binary target built by cmake depends on the
configuration type when using the Visual Studio generators. Is it
possible to pass this path the ctest without having to run ctest with
the -c option?
I'd like to do the following:
I create an executable with cmake as follows, and add a test for it:
add_executable( my_test main.cpp )
add_test( test_name my_test )
Let's assume this executable gets built in bin_path\debug or
bin_path\release, dependent on the configuration. Cmake generates the
following line in the CTestTestfile.cmake:
ADD_TEST( test_name bin_path/my_test )
Note that the my_test path will not contain the executable, it will be
in a configuration dependent subdirectory. However, when running
ctest, ctest will automatically pick a configuration and will change
the path in CTestTestfile.cmake to the right path for this
configuration.
In my case i'd like to call a python script to which i pass the
executables name including path, so i'd to do something like:
add_test( python test ${PYTHON_EXECUTABLE} my_test )
In this case, my_test does not get expanded in CTestTestfile.cmake
to bin_path/my_test. Also, if I replace my_test here with
bin_path/my_test, ctest will not do the automatic substitution to of
the base path to the right configuration dependent path anymore.
Alternatively, i tried replacing the add_test line with the add_test(
NAME COMMAND ...) syntax, but then all the tests are inside ctest
configuration specific ifs. Basically the tests drops of the list of
tests when just running ctest, it only appears when running ctest
with an explicit configuration, e.g. ctest -C Debug.
Is it possible to have ctest automatically figure out the right path
to a cmake-built binary, without having to run ctest with an explicit
configuration?
AFAIK, the generator expressions have been added to ADD_TEST() in
order to address this issue; have you already tried the following?
ADD_TEST(NAME python test
COMMAND ${PYTHON_EXECUTABLE} $TARGET_FILE:my_test)
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] Support for multiple components in cpack (reloaded)
On Aug 21, 2010, at 6:21 AM, Eric Noulard wrote: 2010/8/21 Eric Noulard eric.noul...@gmail.com: [...] They change the number and the contents of the generated packages: 3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all components GROUPS 3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all COMPONENTS 3.c) CPACK_COMPONENTS_IGNORE_GROUPS means you want to get 1 package per COMPONENT (the default is 1 package per GROUP) argh push ENTER too fast... The difference between 3.a) and 3.b) may not be obvious but one should know that COMPONENT install will install components which are specified in CPACK_COMPONENTS_ALL (component which are not specified there won't be installed at all in any case) BUT some component may NOT BELONG TO ANY GROUP. In this case 3.b will include the orphan component whereas 3.a will NOT. last but not least there exist a special component automatically generated by CPack the component is named Unspecified and contains all INSTALLed file/targets/... which do not specify COMPONENT. If Unspecified is contained in CPACK_COMPONENTS_ALL then again 3.b will include the Unspecified component whereas 3.a will NOT. 3.c should always include ALL COMPONENTS specified in CPACK_COMPONENTS_ALL. Note that there is existing feature of CPack which would just make CPack ignore the component stuff this is CPACK_MONOLITHIC_INSTALL. The CPACK_MONOLITHIC_INSTALL has a different objective because: * CPACK_MONOLITHIC_INSTALL is used AT CMake time whereas 3.a, 3.b and 3.c may be used AT CPack time. Thus if you use CPACK_MONOLITHIC_INSTALL all the CPack time component stuff will be ignored. * One other difference is the fact that CPack time component control variable may let you package only a chosen portion of the INSTALLed things CPACK_MONOLITHIC_INSTALL cannot do that. Any feedback on this stuff is welcomed. After that I will go on for RPM and DEB component support which will be similar but may be more difficult because it has to support inter-component dependencies which is just not handled at all for Archive Generators. I wondered if one would typically use groups if their project contained sub projects, and the sub projects had different conventions for the component names. Would grouping be a way to overcome that? It doesn't seem so, because in the wiki, the nsis example shows a hierarchy of components. Or does one just make a common display name for multiple components? 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] Support for multiple components in cpack (reloaded)
Am Saturday 21 August 2010 schrieb Eric Noulard: They change the number and the contents of the generated packages: 3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all components GROUPS 3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1 means you want to get a single package whose content is the merge of all COMPONENTS 3.c) CPACK_COMPONENTS_IGNORE_GROUPS means you want to get 1 package per COMPONENT (the default is 1 package per GROUP) AFAICS those are exlusive, so why don't you use a single variable with 3 different values that prints a big fat warning if it is set to anything else to make error detection easier? 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
