Re: [cmake-developers] Change type of CMAKE_OSX_SYSROOT to STRING instead of PATH
This patch can't quite be right. After this patch, the value of CMAKE_OSX_SYSROOT will be: macosx10.5;STRING;PATH;The product will be built agai... You meant to change the PATH to a STRING I think -- but even so, this change should have no actual effect on the behavior of CMake. The type of a variable is merely a hint to the gui programs on what type of edit control to use for editing the variable's value. Aside from that, there should be no observable effect. The effect you're seeing as a result of this mistaken patch is probably due to the fact that CMAKE_OSX_SYSROOT is not being *cached* anymore, not because you've changes a cache entry's type I am afraid we'll have to do a round of fixes for Xcode 4 support if it no longer accepts full path to the SDK as a valid value for this property. On Fri, May 27, 2011 at 5:54 AM, Johan Björk p...@spotify.com wrote: Hi guys, Attached patch that changes the type of the CMAKE_OSX_SYSROOT variable. All versions of XCode accept in addition to the full path to the SDK, also a symbolic name, ie 'macosx10.5' or similar. To make things worse, some versions of XCode 4 doesn't seem to like the full paths at all. Without this patch, it already works fine, until you try to use TRY_COMPILE() or the like, where your symbolic name will be converted to a full path. '/Users/phb/DEV/.../build/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/macosx10.5' Should be a trivial fix, there should be no reason where we want automatic path expansion on that value. Thanks /Johan ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Change type of CMAKE_OSX_SYSROOT to STRING instead of PATH
uh, sorry about the noise, you are right, the patch is completely bogus. I wonder where it converts it to a path, will have to look into a bit more. thanks /Johan On Fri, May 27, 2011 at 12:17 PM, David Cole david.c...@kitware.com wrote: This patch can't quite be right. After this patch, the value of CMAKE_OSX_SYSROOT will be: macosx10.5;STRING;PATH;The product will be built agai... You meant to change the PATH to a STRING I think -- but even so, this change should have no actual effect on the behavior of CMake. The type of a variable is merely a hint to the gui programs on what type of edit control to use for editing the variable's value. Aside from that, there should be no observable effect. The effect you're seeing as a result of this mistaken patch is probably due to the fact that CMAKE_OSX_SYSROOT is not being *cached* anymore, not because you've changes a cache entry's type I am afraid we'll have to do a round of fixes for Xcode 4 support if it no longer accepts full path to the SDK as a valid value for this property. On Fri, May 27, 2011 at 5:54 AM, Johan Björk p...@spotify.com wrote: Hi guys, Attached patch that changes the type of the CMAKE_OSX_SYSROOT variable. All versions of XCode accept in addition to the full path to the SDK, also a symbolic name, ie 'macosx10.5' or similar. To make things worse, some versions of XCode 4 doesn't seem to like the full paths at all. Without this patch, it already works fine, until you try to use TRY_COMPILE() or the like, where your symbolic name will be converted to a full path. '/Users/phb/DEV/.../build/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/macosx10.5' Should be a trivial fix, there should be no reason where we want automatic path expansion on that value. Thanks /Johan ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012231]: [PATCH] Fixes to spelling XCode vs Xcode, notably in man page
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12231 == Reported By:Sean McBride Assigned To: == Project:CMake Issue ID: 12231 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2011-05-27 18:16 EDT Last Modified: 2011-05-27 18:16 EDT == Summary:[PATCH] Fixes to spelling XCode vs Xcode, notably in man page Description: The attached patch corrects various XCode to Xcode, notably in the man page. == Issue History Date ModifiedUsername FieldChange == 2011-05-27 18:16 Sean McBride New Issue 2011-05-27 18:16 Sean McBride File Added: 0002-fixed-XCode-Xcode-typos-notabally-in-man-page.patch == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Cannot find source file: *.rc
On 05/26/2011 06:45 PM, aaron_wri...@selinc.com wrote: From: Michael Wild them...@gmail.com To: cmake@cmake.org Date: 05/25/2011 10:08 PM Subject: Re: [CMake] Cannot find source file: *.rc Sent by: cmake-boun...@cmake.org On 05/25/2011 11:40 PM, aaron_wri...@selinc.com wrote: I use mc.exe to generate an *.rc file and some headers for my program. The *.rc file is listed as an output of a custom command and as a source to an executable. During configuration CMake tells me it can't find a source file and lists the *.rc file. I've check the generated property of the *.rc file and it is true, so why does CMake expect it to be present during configuration? I've tried to make a small example, but when I try to do that everything works. What I'm looking for is a reason why it would only effect large build systems on not small build system, or why does this only effect this *.rc and none of the other twenty or thirty files I generate? Is there something special about *.rc files? I'm really just grabbing at straws here because I've been trying to fix this for months, with no luck. So any ideas are welcome. --- Aaron Wright Is the add_custom_command call generating the *.rc file in the same directory as your add_executable call? Michael It is neither in the same CMakeLists.txt nor is the *.rc file generated anywhere close to the executable. I did work around this by writing a dummy file at configure time with FILE(WRITE. Thought that seems a little hacky. That is the problem. GENERATED source files only seem to work when used in the same directory. 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] Copying files (different name)
Using configure_file with the COPYONLY flag is a reasonable technique: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:configure_file On Thu, May 26, 2011 at 8:38 PM, Tyler ty...@cryptio.net wrote: Don't know if file() will work but configure_file() will. You might want the NO_REPLACE flag or whatever it's called to prevent accidental variable interpolation. tyler On Thu, May 26, 2011 at 4:46 PM, Nicholas Yue yue.nicho...@gmail.com wrote: Hi, With the FILE ( COPY .. DESTINATION) command, is there a way to create a second copy of a file at the DESTINATION with a different name ? In my case, my DESTINATION is the same as the original location. Basically, I am trying to duplicate this command line copy header.h.vc header.h Regards ___ 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 ___ 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] CPack/NSIS: Behaviour when creating shortcuts and sequence of install options
Hi @all, currently I am working on an installer with CPack/NSIS and I noticed a behaviour which I wanted to know if it is common or not. When enabling the option to create a shortcut on the desktop, but also enabling Don't create shortcuts when determining the directory for the start menu, then no shortcuts are generated at all. Is this the usual behaviour, as the generic wording Don't create shortcuts suggests? Is there any possibility to change the order of appearance of the options during install out of CMake? Greetings, Philipp ___ 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] Cannot find source file: *.rc
On 05/27/2011 11:46 AM, Michael Wild wrote: On 05/26/2011 06:45 PM, aaron_wri...@selinc.com wrote: From: Michael Wild them...@gmail.com To: cmake@cmake.org Date: 05/25/2011 10:08 PM Subject: Re: [CMake] Cannot find source file: *.rc Sent by: cmake-boun...@cmake.org On 05/25/2011 11:40 PM, aaron_wri...@selinc.com wrote: I use mc.exe to generate an *.rc file and some headers for my program. The *.rc file is listed as an output of a custom command and as a source to an executable. During configuration CMake tells me it can't find a source file and lists the *.rc file. I've check the generated property of the *.rc file and it is true, so why does CMake expect it to be present during configuration? I've tried to make a small example, but when I try to do that everything works. What I'm looking for is a reason why it would only effect large build systems on not small build system, or why does this only effect this *.rc and none of the other twenty or thirty files I generate? Is there something special about *.rc files? I'm really just grabbing at straws here because I've been trying to fix this for months, with no luck. So any ideas are welcome. --- Aaron Wright Is the add_custom_command call generating the *.rc file in the same directory as your add_executable call? Michael It is neither in the same CMakeLists.txt nor is the *.rc file generated anywhere close to the executable. I did work around this by writing a dummy file at configure time with FILE(WRITE. Thought that seems a little hacky. That is the problem. GENERATED source files only seem to work when used in the same directory. Michael This is even documented explicitly: In the CMake manual, search for in the same directory (CMakeLists.txt file), and see FAQ 4.7. If a custom command's output is to be referred to from another CMakeLists.txt file, one must trigger it by a custom target, e.g. Moreover, note that source properties like GENERATED are not only associated to source files, but also restricted to directories, i.e. a source file marked as GENERATED in one CMakeLists.txt won't bear this mark in another CMakeLists.txt. 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] INSTALL with RENAME
On 05/26/2011 09:42 PM, J Decker wrote:
It's a windows XP target, so symlinks aren't doable...
On Thu, May 26, 2011 at 12:12 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Thursday 26 May 2011, J Decker wrote:
How do I install a single target as multiple names? (for something like
busybox)
Did you try install(CODE ... ) or install(SCRIPT ... ) to create symlinks at
install time ?
Alex
AFAIK, the RENAME clause isn't available for the INSTALL(TARGETS ...)
signature, and when using INSTALL(CODE|SCRIPT ...), you will probably
lose the INSTALL() command's advanced features, e.g. the COMPONENT or
CONFIGURATIONS clause. Therefore, I'd suggest to create the symlinks/
copies already in the build tree via a POST_BUILD custom command and
install them afterwards regularly by INSTALL(PROGRAMS ...):
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MULTINST C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
INSTALL(TARGETS main DESTINATION bin)
FOREACH(i rm ls mv cp)
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
COMMAND ${CMAKE_COMMAND} -E create_symlink
$TARGET_FILE_NAME:main ${CMAKE_BINARY_DIR}/util_${i})
INSTALL(PROGRAMS ${CMAKE_BINARY_DIR}/util_${i} DESTINATION bin)
ENDFOREACH()
Instead of create_symlink, you might also use copy_if_different.
Besides, having the symlinks/copies already available in the
build tree could be convenient w.r.t. testing.
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] CMake pod cast
On Friday 27 May 2011, Bill Hoffman wrote: Last week I did an interview for the High Performance Computing (HPC) and Research Computing Podcast. It can be found here: http://www.rce-cast.com/ Just found that CMake (and also VTK) is also covered here: http://www.aosabook.org/en/ Cool :-) Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake pod cast
On 2011-05-26 22:14-0400 Bill Hoffman wrote: Last week I did an interview for the High Performance Computing (HPC) and Research Computing Podcast. It can be found here: http://www.rce-cast.com/ I enjoyed that interview. For example, I suspect that autotools-oriented guy will take a look at CMake because of the information you gave him. Thanks for that link. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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 pod cast
On 5/27/2011 3:11 PM, Alexander Neundorf wrote: On Friday 27 May 2011, Bill Hoffman wrote: Last week I did an interview for the High Performance Computing (HPC) and Research Computing Podcast. It can be found here: http://www.rce-cast.com/ Just found that CMake (and also VTK) is also covered here: http://www.aosabook.org/en/ Cool :-) I just finished a blog post about the book: http://www.kitware.com/blog/home/post/136 -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-commits] CMake branch, master, updated. v2.8.4-477-g909bab1
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 909bab1f4fe877f7627c3702cb1732f70d97 (commit) from 1e885b1bb589fd488ba63e7b7f6530a915670b32 (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=909bab1f4fe877f7627c3702cb1732f70d97 commit 909bab1f4fe877f7627c3702cb1732f70d97 Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat May 28 00:01:08 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat May 28 00:13:04 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 2f0ad63..71e8146 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 05) # 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
