Re: [cmake-developers] fphsa capitalization
On 2010-08-14 16:25+0200 Eric Noulard wrote: I know this may seems overkill, because we are only speaking about ExactCase vs UPPERCASE, but if we take the backward compatibilty seriously and want to progress towards to ExactCMake, may be it's a possible idea. Now I think I just unveil myself a CMake pandora box, the whatever case getter I propose is not too far away from the MACRO(WhatEvERcase) or FUNCTION(WHATeverCase) behavior. I let you run the attached cmake script and tell me if you knew this flexible CMake command naming was true for MACRO and FUNCTION too ? This is genuine consistent but why doing this on macro and not on vars? As a CMake-based build-system implementer for various software packages, I was well aware of and do like the convenience of case-insensitive use of commands, macros, and functions. However, variables are a different story and _in general_ there you want to maximize the possibilities for the largest possible namespace so case insensitivity would be a bad idea for variables _in general_. However, for the specific case of the variables set by find modules, the present mess is unacceptable, and CMake should move to an enforced consistent naming convention as soon as possible. I will let others more competent than me in CMake internals comment on the technical merits of Eric's proposals, but I think the idea of removing a lot of the pain of converting to a consistent naming convention for the variables set by find modules using technical means is a good one. Assuming Eric's or similar proposals are implemented to remove that conversion pain, I agree with Brad that since we already must use exact case for referring to the find module name with the find_package command, it makes a lot of sense to use that same exact-case name as a prefix for the variables set by that find module. My hope is that with the conversion pain removed, Alex would be willing to go along with the exact case naming convention so that solving the current naming convention mess is not delayed too much longer. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] fphsa capitalization
On Saturday 14 August 2010, you wrote: ... find_package command, it makes a lot of sense to use that same exact-case name as a prefix for the variables set by that find module. My hope is that with the conversion pain removed, I'm afraid this wouldn't remove my personal (KDE's) conversion pain, see below. Alex would be willing to go along with the exact case naming convention so that It's not that I don't like ExactCase, I just don't think changing from the current de-facto standard (90% UPPERCASE) without real need to a different one is a good idea. Or in other words: I don't feel like going through the 67 find-modules in kdelibs and fixing them to provide also Exact case, and while doing this answering emails from KDE developers wondering what I'm doing and why (CMake developers decided that the new standard is ExactCase). Also, in KDE there are not only the find-modules in kdelibs (the 89 files I mentioned, there are find modules in the other KDE modules too (kdenetwork, kdebase, kdegraphics, koffice, extragear, ...) They are not that many, but I assume that most of the modules there are also using UPPERCASE. OTOH fixing the 6 ExactCase files to provide also UPPERCASE sounds reasonably to me. I just checked cmake 2.4.1 (from early 2006, when we started to use cmake in KDE): Checked 63 files, exact=0, allUp=21, both=21 unclear=21 And cmake 2.4.3: Checked 64 files, exact=2, allUp=21, both=21 unclear=20 (FindBoost and FindSubversion) To me this shows that in 2.4.x UPPERCASE indeed was the standard, and this is what FPHSA() does. Both naming rules are very simple (ExactCase and ALLUPPERCASE). What is the benefit we gain from using ExactCase compared to UPPERCASE ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] D support
Hello List, I've taken an interested in D lately and in order to play around there, of course I want CMake. There was an effort in 2007 to support D, since abandoned, but I'm trying to take up the cause. The project is just getting off the ground here: http://code.google.com/p/cmaked2/source/checkout. At this point, cmaked is only known to work for the dmd compiler in 32-bit Fedora 13. I based D support on the C compiler support in the latest git version. Mostly just copying and tweaking without deep insight. So, my questions: 1) Is this the right place to post and review the code? I would much appreciate the guidance. 2) Can someone provide an overview of steps necessary to make D support an official part of CMake? Is this even reasonable? 3) Is there some cross-platform test infrastructure I can (eventually) piggy back onto? Thanks, -steve ___ 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] Framework + Unix tools help
On 13. Aug, 2010, at 23:29 , Carlos Gonçalves wrote:
On 2010/08/13, at 08:52, Michael Wild wrote:
On 12. Aug, 2010, at 22:41 , Carlos Gonçalves wrote:
Hi,
On 2010/08/12, at 20:15, Chris Wolf wrote:
On 8/12/10 10:20 AM, Carlos Gonçalves wrote:
Hi,
I have already looked everywhere possible (so to speak) on how to create
a Framework + Unix tools as described in [1] but found no examples. So
far I was able to create a Framework only [2].
I'm trying to add Mac OS X support to GeneratorRunner[3] and my current
CMakeLists.txt can be viewed in [4]. Any help would be appreciated :-)
Thanks,
Carlos Gonçalves
[1]
http://www.cmake.org/Wiki/CMake:Bundles_And_Frameworks#Framework_.2B_Unix_tools
[2] http://www.cmake.org/Wiki/CMake:Bundles_And_Frameworks#Framework_only
[3] http://qt.gitorious.org/pyside/generatorrunner
[4] http://pastebin.com/p7CKYP2z
I am not certain about your main question - but looking at your code, I
see you have:
add_custom_target(dist...
...which creates a file, ChangeLog.txt from the git log, then creates an
archive. You only need to create the ChangeLog.txt file here; you
don't need to create temp dirs and invoke tar and bzip2 - cpack can
do that for you, via the defined package generators.
That's a custom target to create a new release tarball, so nothing to do
with my question :-)
For creating source and/or binary archives, just use one of the CPack
package generators:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#TBZ2
To create the configured binary package(s), either invoke make package
or invoke cpack directly: cpack
To create the configured source package, either invoke cpack via:
make package_source or directly via:
cpack --config ./CPackSourceConfig.cmake
Sorry I couldn't answer your real question... ;)
My fault, not yours. Ok, let me explain it better.
GeneratorRunner builds successfully on Linux and installs just fine. Now, I
want to add Mac OS X support on it. Since GeneratorRunner contains an
application (generatorrunner) and a library (genrunner) the installation
file hierarchy should be, for what I have understand, something equivalent
to the example given in
http://www.cmake.org/Wiki/CMake:Bundles_And_Frameworks#Framework_.2B_Unix_tools
-- Installing: /Library/Frameworks/genrunner.framework
-- Installing: /Library/Frameworks/genrunner.framework/genrunner
-- Installing: /Library/Frameworks/genrunner.framework/Resources
-- Installing: /Library/Frameworks/genrunner.framework/Versions
-- Installing: /Library/Frameworks/genrunner.framework/Versions/0.6.1
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/genrunner
-- Installing: /Library/Frameworks/genrunner.framework/Versions/0.6.1/lib
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/lib/cmake
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/lib/cmake/GeneratorRunner-0.6.1
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/lib/cmake/GeneratorRunner-0.6.1/GeneratorRunnerConfig.cmake
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/lib/cmake/GeneratorRunner-0.6.1/GeneratorRunnerConfigVersion.cmake
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/lib/pkgconfig
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/lib/pkgconfig/generatorrunner.pc
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/Resources
-- Installing:
/Library/Frameworks/genrunner.framework/Versions/0.6.1/Resources/Info.plist
-- Installing: /Library/Frameworks/genrunner.framework/Versions/Current
-- Installing: /Applications/GeneratorRunner/bin/generatorrunner
My question is mainly about file
/Applications/GeneratorRunner/bin/generatorrunner which, although I've set
it to be installed there for testing purposes, what I want is it so be
installed either in
/Library/Frameworks/genrunner.framework/Versions/0.6.1/Commands/generatorrunner
or in
Library/Frameworks/genrunner.framework/Versions/0.6.1/bin/generatorrunner
(I truly don't know what the difference between Commands/ and bin/ is since
they both contain executables), but I don't know how to do it. I tried
messing with RUNTIME DESTINATION setting it to bin but that didn't help.
Hope I have clarified my question ;-)
Thanks,
Carlos Gonçalves
Now you only have to use execute_process(COMMAND ${CMAKE_COMMAND} -E
create_symlink ...) to create a symlink somewhere in your build tree that
points to the executable inside the framework (either using a relative path
or the absolute install-path) and then install it using install(FILES ...).
But how do I install the executable inside the framework dir? What I have now
is:
install(TARGETS genrunner generatorrunner
RUNTIME DESTINATION bin
FRAMEWORK DESTINATION Library/Frameworks
LIBRARY DESTINATION lib${LIB_SUFFIX}
Re: [CMake] D support
On 2010-08-13 23:30-0700 SK wrote: Hello List, I've taken an interested in D lately and in order to play around there, of course I want CMake. There was an effort in 2007 to support D, since abandoned, but I'm trying to take up the cause. The project is just getting off the ground here: http://code.google.com/p/cmaked2/source/checkout. At this point, cmaked is only known to work for the dmd compiler in 32-bit Fedora 13. I based D support on the C compiler support in the latest git version. Mostly just copying and tweaking without deep insight. PLplot has also copied and tweaked an older D language support effort for CMake. It appears to work well for my Linux platform, but I don't know how wide-spread the testing has been on other platforms. In any case, you may want to review what we have done with D language support at http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/ 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] Weirdness with shared library, RPATH policy on MacOS
On 13. Aug, 2010, at 20:58 , Michael Wild wrote: [...] Sure, http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu, but it's pretty complex... Michael Attached is a tiny project which works for me on both Linux and Mac. Michael greetings.tgz Description: Binary data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to build .ax libraries with cmake?
Hi all, The source and binary are available here: http://tmhare.mvps.org/downloads/vcam.zip http://tmhare.mvps.org/downloads/vcam.zip How to build .ax libraries with 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] Problem with include directory ordering in wxWidgets_INCLUDE_DIRS
I have added this to the bug database myself.
Roger
On 10/08/2010 21:58, Roger James wrote:
Please can someone with access to the bug database raise this as a
problem.
The CMake module FindwxWidgets.cmake sets up an a variable called
wxWidgets_INCLUDE_DIRS which is intended to be used as the source of
additional include directories to be searched by various build tools.
The code that sets this up looks like this.
# Set wxWidgets main include directory.
IF(EXISTS ${WX_ROOT_DIR}/include/wx/wx.h)
SET(wxWidgets_INCLUDE_DIRS ${WX_ROOT_DIR}/include)
ELSE(EXISTS ${WX_ROOT_DIR}/include/wx/wx.h)
DBG_MSG(wxWidgets_FOUND FALSE because
WX_ROOT_DIR=${WX_ROOT_DIR} has no ${WX_ROOT_DIR}/include/wx/wx.h)
SET(wxWidgets_FOUND FALSE)
ENDIF(EXISTS ${WX_ROOT_DIR}/include/wx/wx.h)
# Set wxWidgets lib setup include directory.
IF(EXISTS ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h)
LIST(APPEND wxWidgets_INCLUDE_DIRS
${WX_LIB_DIR}/${wxWidgets_CONFIGURATION})
ELSE(EXISTS ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h)
DBG_MSG(WXWIDGET_FOUND FALSE because
${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h does not exists.)
SET(wxWidgets_FOUND FALSE)
ENDIF(EXISTS ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h)
This results in the configuration specific (unicode/non-unicode)
include directories being placed after the generic include directory
in the list. This needs to be the other way round and can cause
duplicate manifest resource problems when linking applications on
windows visual studio platforms. This is caused by the fact that the
file rcdefs.h exists in both the configuration specific include dir
and in the generic include dir. However the version of rcdefs.h in the
generic include dir is only intended to be used if configuration
specific ones are not found.
The gory details are that the generic rcdefs.h does not contain a
definition for WX_MSC_FULL_VER which is used to stop wxWidgets trying
to link in its own manifest resource when newer versions of the of the
Microsoft Compiler that provide their own manifests are being used.
I suggest that the two pieces of CMake code are swapped round and the
SET and LIST commands modified as appropriate.
Having the include dirs in the current order may well cause other
obscure problems as well.
Cheers,
Roger
___
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] Weirdness with shared library, RPATH policy on MacOS
On 8/14/10 3:35 AM, Michael Wild wrote: On 13. Aug, 2010, at 20:58 , Michael Wild wrote: [...] Sure, http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu, but it's pretty complex... Michael Attached is a tiny project which works for me on both Linux and Mac. Michael That's awesome! Thanks so much. From your example, and looking at the documentation: http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH ...I can see the difference now - you are setting CMAKE_INSTALL_NAME_DIR. (which is not needed or used on Linux/ELF) What I had been trying to do along these lines was a per-target setting: set_target_properties(usbDynamic PROPERTIES INSTALL_NAME_DIR /tmp/local/lib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib INSTALL_NAME_DIR /tmp/local/lib) None of those were working for me. I will incorporate your setting in my project. Thanks, -Chris ___ 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] Weirdness with shared library, RPATH policy on MacOS
On 14. Aug, 2010, at 15:13 , Chris Wolf wrote: On 8/14/10 3:35 AM, Michael Wild wrote: On 13. Aug, 2010, at 20:58 , Michael Wild wrote: [...] Sure, http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu, but it's pretty complex... Michael Attached is a tiny project which works for me on both Linux and Mac. Michael That's awesome! Thanks so much. From your example, and looking at the documentation: http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH ...I can see the difference now - you are setting CMAKE_INSTALL_NAME_DIR. (which is not needed or used on Linux/ELF) What I had been trying to do along these lines was a per-target setting: set_target_properties(usbDynamic PROPERTIES INSTALL_NAME_DIR /tmp/local/lib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib INSTALL_NAME_DIR /tmp/local/lib) None of those were working for me. I will incorporate your setting in my project. Thanks, -Chris Aaaah, I see. The INSTALL_RPATH should have been /tmp/local/lib. And RPATH is only a Linux thing, while install_name is a Mac OS X thing ;-) 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] How to build .ax libraries with cmake?
2010/8/14 Mr Shore shore.cl...@gmail.com: Hi all, The source and binary are available here: http://tmhare.mvps.org/downloads/vcam.zip How to build .ax libraries with cmake? May be some dummy newbie questions but ... - Can tell us a little about **what are** AX libraries? - Some documentation? URL ? - Which tool(s) do you currently use to build those AX ? etc... -- 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] Weirdness with shared library, RPATH policy on MacOS
On 8/14/10 10:31 AM, Michael Wild wrote: On 14. Aug, 2010, at 15:13 , Chris Wolf wrote: On 8/14/10 3:35 AM, Michael Wild wrote: On 13. Aug, 2010, at 20:58 , Michael Wild wrote: [...] Sure, http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu, but it's pretty complex... Michael Attached is a tiny project which works for me on both Linux and Mac. Michael That's awesome! Thanks so much. From your example, and looking at the documentation: http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH ...I can see the difference now - you are setting CMAKE_INSTALL_NAME_DIR. (which is not needed or used on Linux/ELF) What I had been trying to do along these lines was a per-target setting: set_target_properties(usbDynamic PROPERTIES INSTALL_NAME_DIR /tmp/local/lib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib INSTALL_NAME_DIR /tmp/local/lib) None of those were working for me. I will incorporate your setting in my project. Thanks, -Chris Aaaah, I see. The INSTALL_RPATH should have been /tmp/local/lib. And RPATH is only a Linux thing, while install_name is a Mac OS X thing ;-) Michael Actually, /tmp/local/lib is just for testing - my intention is to use /usr/local/lib. Also RPATH on Mac OSX is no different then Linux, SunOS, etc. - only the mechanism to change it is. For example, CMake appears to use perform direct modification of ELF-formatted binaries, apparently to avoid relinking upon installation (i.e. running the generated cmake_install.cmake) It does this via the undocumented FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE,... routines. which are called indirectly via cmInstallTargetGenerator::PostReplacementTweaks/cmInstallTargetGenerator::AddChrpathPatchRule For some reason (maybe to accommodate frameworks) instead of polymorphically implementing cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath to handle the ELF *or* Darwin cases (which would have allowed AddChrpathPatchRule to work for ELF *and* Darwin) - a separate piece of logic was implemented for PostReplacementTweaks called, cmInstallTargetGenerator::AddInstallNamePatchRule, which invokes the OSX utility install_name_tool to change the RPATH in shared libraries and executables. The way I see it (and I could be wrong) there is divergence between the logic of AddChrpathPatchRule (ELF RPATH logic) and AddInstallNamePatchRule (Darwin RPATH logic) Ideally, if cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath were polymorphic for ELF and Darwin, you would only need AddChrpathPatchRule and not AddInstallNamePatchRule, such that the FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE routines would function the same for ELF and Darwin and the generated cmake_install.cmake would look the same for both of these platforms - as a result, the documented behavior (http://www.cmake.org/Wiki/CMake_RPATH_handling) would be identical for ELF and Darwin cases. Well, that's my two cents... Thanks again for your help, -Chris ___ 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] Visual Studio Express projects don't inherit from parent
I am using CMake 2.8.2 on a 64-bit version of Windows 7 Enterprise. When I try to configure my project to build for Visual Studio 2010 Express, I get compiler warnings building the projects because none of the projects are set to inherit from parent or project defaults for include directories. This prevents certain header files common to all projects from being found, thus the compiler errors. How do I configure my CMake scripts to that projects for Visual Studio 2010 Express will inherit the required include directories? ___ 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 fails to find test command : bug in use of FileExists() + suggested fix.
One of my test cases needs sudo to run (its listening on privileged ports).
If I add
ADD_TEST( SERVER /usr/bin/sudo
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Server${SUFFIX} --daemon )
CMake complains that it can¹t find sudo.
[ d042 ] make test
Running tests...
Test project /Users/richard/BUILD
Start 1: SERVER
Could not find executable /usr/bin/sudo
Looked in the following places:
/usr/bin/sudo
/usr/bin/sudo
/usr/bin/Release/sudo
/usr/bin/Release/sudo
/usr/bin/Debug/sudo
/usr/bin/Debug/sudo
...
However (on OS X and Linux) sudo is not readable (although it is
executable).
In Source/CTest/cmCTestTestHandler.cxx (line 1494) you¹re using
cmSystemTools::FileExists(attempted[ai].c_str() ) to test for the presence
of the testcase.
Looking in Source/kwsys/SystemTools.cxx line 919 shows that on non-Windows
systems its using access(path, R_OK), which checks to see if the path has
read permissions.
Might I suggest replacing the call to FileExists()
Source/CTest/cmCTestTestHandler.cxx in with a new test -
FileIsExecutable() since the only requirement is to be able to execute the
program, not read it.
Thanks,
Richard.
___
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] Weirdness with shared library, RPATH policy on MacOS
On 8/14/10 4:01 PM, Michael Wild wrote: On 14. Aug, 2010, at 18:26 , Chris Wolf wrote: On 8/14/10 10:31 AM, Michael Wild wrote: On 14. Aug, 2010, at 15:13 , Chris Wolf wrote: On 8/14/10 3:35 AM, Michael Wild wrote: On 13. Aug, 2010, at 20:58 , Michael Wild wrote: [...] Sure, http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu, but it's pretty complex... Michael Attached is a tiny project which works for me on both Linux and Mac. Michael That's awesome! Thanks so much. From your example, and looking at the documentation: http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH ...I can see the difference now - you are setting CMAKE_INSTALL_NAME_DIR. (which is not needed or used on Linux/ELF) What I had been trying to do along these lines was a per-target setting: set_target_properties(usbDynamic PROPERTIES INSTALL_NAME_DIR /tmp/local/lib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib) -=or=- set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH /tmp/local/lib/libusb-1.dylib INSTALL_NAME_DIR /tmp/local/lib) None of those were working for me. I will incorporate your setting in my project. Thanks, -Chris Aaaah, I see. The INSTALL_RPATH should have been /tmp/local/lib. And RPATH is only a Linux thing, while install_name is a Mac OS X thing ;-) Michael Actually, /tmp/local/lib is just for testing - my intention is to use /usr/local/lib. Also RPATH on Mac OSX is no different then Linux, SunOS, etc. - only the mechanism to change it is. For example, CMake appears to use perform direct modification of ELF-formatted binaries, apparently to avoid relinking upon installation (i.e. running the generated cmake_install.cmake) It does this via the undocumented FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE,... routines. which are called indirectly via cmInstallTargetGenerator::PostReplacementTweaks/cmInstallTargetGenerator::AddChrpathPatchRule For some reason (maybe to accommodate frameworks) instead of polymorphically implementing cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath to handle the ELF *or* Darwin cases (which would have allowed AddChrpathPatchRule to work for ELF *and* Darwin) - a separate piece of logic was implemented for PostReplacementTweaks called, cmInstallTargetGenerator::AddInstallNamePatchRule, which invokes the OSX utility install_name_tool to change the RPATH in shared libraries and executables. The way I see it (and I could be wrong) there is divergence between the logic of AddChrpathPatchRule (ELF RPATH logic) and AddInstallNamePatchRule (Darwin RPATH logic) Ideally, if cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath were polymorphic for ELF and Darwin, you would only need AddChrpathPatchRule and not AddInstallNamePatchRule, such that the FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE routines would function the same for ELF and Darwin and the generated cmake_install.cmake would look the same for both of these platforms - as a result, the documented behavior (http://www.cmake.org/Wiki/CMake_RPATH_handling) would be identical for ELF and Darwin cases. Well, that's my two cents... Thanks again for your help, -Chris No, the two mechanisms are fundamentally different. On Linux the RPATH is a search path (think LD_LIBRARY_PATH) that is encoded into the binary. The linker only embeds the library name, no directory information. The loader then first searches these directories for the linked libraries, and then proceeds to search LD_LIBRARY_PATH and the directories defined in ld.conf. On Mac OS X, the install_name is a file name encoded into the library itself. When another binary is linked against this library, the linker hard-codes this file name into the binary, no matter what the actual location of the library is. The loader then tries to load that library using the hard-coded install_name from the binary, and only if that fails, uses DYLD_FALLBACK_LIBRARY_PATH. I hope this clarifies things a bit. Michael Actually, I would say that the Darwin dynamic loader behavior is a super-set of the Linux dynamic loader. You can set RPATHs in an executable via the linker option -rpath /tmp/bar and instead of single colon-delimited path, you just specify multiple -rpath /some/path options. Then you can set the install_name on the dependent shared libraries to @rpath/mylib.dylib which is used to locate the shared library via the rpath(s) in the executable. This would be the same behavior as Linux: See: http://bit.ly/bNert1 http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html http://bit.ly/csQGqb However, I am not necessarily advocating doing that, since that is not the convention used to deliver simple (i.e. not framework or bundle or plugins) apps and libraries. All I am suggesting is that it
[Cmake-commits] CMake branch, next, updated. v2.8.2-429-gb053112
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 b0531123e405d3d6daca72894734215fdae20170 (commit)
via 1a3ad5c615be02cd18fe8e166b16ee15f821df72 (commit)
via b50c15915ac5cca79e00bf438dacd074fe531978 (commit)
from 2e65a1fa543e4e148eccfab4d99287c9b1bf386a (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=b0531123e405d3d6daca72894734215fdae20170
commit b0531123e405d3d6daca72894734215fdae20170
Merge: 2e65a1f 1a3ad5c
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Aug 14 04:54:52 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Aug 14 04:54:52 2010 -0400
Merge topic 'libarchive-wrapper' into next
1a3ad5c Add XZ compress support to libarchive-wrapper
b50c159 Add ZIP archive format and LZMA compress support to
libarchive-wrapper
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a3ad5c615be02cd18fe8e166b16ee15f821df72
commit 1a3ad5c615be02cd18fe8e166b16ee15f821df72
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Fri Aug 13 17:51:27 2010 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Fri Aug 13 17:51:27 2010 +0200
Add XZ compress support to libarchive-wrapper
This is not needed but it does not cost much to do it for all
potentially supported format in libarchive. XZ and LZMA are not
builtin libarchive and require external lib but if
CMAKE_USE_SYSTEM_LIBARCHIVE is ON then we may get it for free.
diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index bea9586..524e53e 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -87,6 +87,14 @@ cmArchiveWrite::cmArchiveWrite(std::ostream os, Compress c,
Type t):
return;
}
break;
+case CompressXZ:
+ if(archive_write_set_compression_xz(this-Archive) != ARCHIVE_OK)
+{
+this-Error = archive_write_set_compression_xz: ;
+this-Error += archive_error_string(this-Archive);
+return;
+}
+ break;
};
#if !defined(_WIN32) || defined(__CYGWIN__)
if (archive_read_disk_set_standard_lookup(this-Disk) != ARCHIVE_OK)
diff --git a/Source/cmArchiveWrite.h b/Source/cmArchiveWrite.h
index 0bd3e9b..ce7f961 100644
--- a/Source/cmArchiveWrite.h
+++ b/Source/cmArchiveWrite.h
@@ -33,7 +33,8 @@ public:
CompressNone,
CompressGZip,
CompressBZip2,
-CompressLZMA
+CompressLZMA,
+CompressXZ
};
/** Archive Type */
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b50c15915ac5cca79e00bf438dacd074fe531978
commit b50c15915ac5cca79e00bf438dacd074fe531978
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Fri Aug 13 17:49:47 2010 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Fri Aug 13 17:49:47 2010 +0200
Add ZIP archive format and LZMA compress support to libarchive-wrapper
This will be needed to use cmArchiveWrire in cmCPackArchiveGenerator
with the same feature set as before. Note that adding zip
support to libarchive-wrapper would also makes it easy to add
a new -E zip command to cmake commands.
diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index 94c97e6..bea9586 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -47,7 +47,7 @@ struct cmArchiveWrite::Callback
};
//
-cmArchiveWrite::cmArchiveWrite(std::ostream os, Compress c):
+cmArchiveWrite::cmArchiveWrite(std::ostream os, Compress c, Type t):
Stream(os),
Archive(archive_write_new()),
Disk(archive_read_disk_new()),
@@ -79,11 +79,47 @@ cmArchiveWrite::cmArchiveWrite(std::ostream os, Compress
c):
return;
}
break;
+case CompressLZMA:
+ if(archive_write_set_compression_lzma(this-Archive) != ARCHIVE_OK)
+{
+this-Error = archive_write_set_compression_lzma: ;
+this-Error += archive_error_string(this-Archive);
+return;
+}
+ break;
};
- archive_read_disk_set_standard_lookup(this-Disk);
- if(archive_write_set_format_pax_restricted(this-Archive) != ARCHIVE_OK)
+#if !defined(_WIN32) || defined(__CYGWIN__)
+ if (archive_read_disk_set_standard_lookup(this-Disk) != ARCHIVE_OK)
+{
+this-Error = archive_read_disk_set_standard_lookup: ;
+this-Error += archive_error_string(this-Archive);
+return;;
+}
+#endif
+ switch (t)
+{
+case TypeZIP:
+ if(archive_write_set_format_zip(this-Archive) != ARCHIVE_OK)
+{
+this-Error = archive_write_set_format_zip: ;
+
[Cmake-commits] CMake branch, next, updated. v2.8.2-433-ga8ba5c6
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 a8ba5c6a93eb1ee33b8197cb02d2e959ba01e52f (commit)
via d570ee7b5a6c1ea69d19af1ac2269af0287d6953 (commit)
via 16168ab0c3549b6953fe95354446508ce3cc945e (commit)
via 34f773ccfec20bb6eeaae9b35458c1767885a4cb (commit)
from b0531123e405d3d6daca72894734215fdae20170 (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=a8ba5c6a93eb1ee33b8197cb02d2e959ba01e52f
commit a8ba5c6a93eb1ee33b8197cb02d2e959ba01e52f
Merge: b053112 d570ee7
Author: Mathieu Malaterre mathieu.malate...@gmail.com
AuthorDate: Sat Aug 14 13:19:55 2010 +0200
Commit: Mathieu Malaterre mathieu.malate...@gmail.com
CommitDate: Sat Aug 14 13:19:55 2010 +0200
Merge branch 'fix-issue-11035' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d570ee7b5a6c1ea69d19af1ac2269af0287d6953
commit d570ee7b5a6c1ea69d19af1ac2269af0287d6953
Author: Mathieu Malaterre mathieu.malate...@gmail.com
AuthorDate: Sat Aug 14 13:18:31 2010 +0200
Commit: Mathieu Malaterre mathieu.malate...@gmail.com
CommitDate: Sat Aug 14 13:18:31 2010 +0200
Fix 11035 : debug/release library configuration mistake
Thanks to Dimitri Kaparis for report
diff --git a/Modules/FindOpenSSL.cmake b/Modules/FindOpenSSL.cmake
index c0cdcb1..d3d7fc2 100644
--- a/Modules/FindOpenSSL.cmake
+++ b/Modules/FindOpenSSL.cmake
@@ -74,8 +74,8 @@ IF(WIN32 AND NOT CYGWIN)
)
if( CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE )
set( OPENSSL_LIBRARIES
-optimized ${SSL_EAY_RELEASE} ${LIB_EAY_RELEASE}
-debug ${SSL_EAY_DEBUG} ${LIB_EAY_DEBUG}
+optimized ${SSL_EAY_RELEASE} debug ${SSL_EAY_DEBUG}
+optimized ${LIB_EAY_RELEASE} debug ${LIB_EAY_DEBUG}
)
else()
set( OPENSSL_LIBRARIES ${SSL_EAY_RELEASE} ${LIB_EAY_RELEASE} )
---
Summary of changes:
Modules/FindOpenSSL.cmake |4 ++--
Source/kwsys/kwsysDateStamp.cmake |2 +-
2 files changed, 3 insertions(+), 3 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.2-435-g2d1510b
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 2d1510b82cb4b3a76df15e25cd76e7ecd8243fcb (commit) via 3e126e45bc1a9b5f3172de0c2baa8523d968f0bd (commit) from a8ba5c6a93eb1ee33b8197cb02d2e959ba01e52f (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=2d1510b82cb4b3a76df15e25cd76e7ecd8243fcb commit 2d1510b82cb4b3a76df15e25cd76e7ecd8243fcb Merge: a8ba5c6 3e126e4 Author: Alex Neundorf neund...@kde.org AuthorDate: Sat Aug 14 21:26:23 2010 +0200 Commit: Alex Neundorf neund...@kde.org CommitDate: Sat Aug 14 21:26:23 2010 +0200 Merge branch 'FixSubversionDoc' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3e126e45bc1a9b5f3172de0c2baa8523d968f0bd commit 3e126e45bc1a9b5f3172de0c2baa8523d968f0bd Author: Alex Neundorf neund...@kde.org AuthorDate: Sat Aug 14 21:25:22 2010 +0200 Commit: Alex Neundorf neund...@kde.org CommitDate: Sat Aug 14 21:25:22 2010 +0200 Change documentation of Subversion_FOUND and SUBVERSION_FOUND. As discussed on cmake-devel, here Subversion_FOUND is the recommended one. Alex diff --git a/Modules/FindSubversion.cmake b/Modules/FindSubversion.cmake index 17fbeab..9bad3b1 100644 --- a/Modules/FindSubversion.cmake +++ b/Modules/FindSubversion.cmake @@ -2,8 +2,8 @@ # The module defines the following variables: # Subversion_SVN_EXECUTABLE - path to svn command line client # Subversion_VERSION_SVN - version of svn command line client -# SUBVERSION_FOUND - true if the command line client was found -# Subversion_FOUND - same as SUBVERSION_FOUND, kept around for compatibility +# Subversion_FOUND - true if the command line client was found +# SUBVERSION_FOUND - same as Subversion_FOUND, set for compatiblity reasons # # The minimum required version of Subversion can be specified using the # standard syntax, e.g. FIND_PACKAGE(Subversion 1.4) --- Summary of changes: Modules/FindSubversion.cmake |4 ++-- 1 files changed, 2 insertions(+), 2 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.2-437-g69f80a9
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 69f80a94a3e132cfa0b009d6f2d030bb7e5de40d (commit)
via 75e727855ae860d4289c9dafa8247a4cb3b5852f (commit)
from 2d1510b82cb4b3a76df15e25cd76e7ecd8243fcb (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=69f80a94a3e132cfa0b009d6f2d030bb7e5de40d
commit 69f80a94a3e132cfa0b009d6f2d030bb7e5de40d
Merge: 2d1510b 75e7278
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Aug 14 22:19:20 2010 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Sat Aug 14 22:19:20 2010 +0200
Merge branch 'FixZLIBVersion' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75e727855ae860d4289c9dafa8247a4cb3b5852f
commit 75e727855ae860d4289c9dafa8247a4cb3b5852f
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Aug 14 22:16:06 2010 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Sat Aug 14 22:16:06 2010 +0200
Fix ZLIB version parsing if no TWEAK version exists
ZLIB_VERSION_STRING was 1.2.3.#define ZLIB_VERSION 1.2.3 here, because
the result of the matching for the tweak version was also appended if there
was no TWEAK version and the regexp failed, which gives as result not
an empty string, but the full string.
Now it is only appended if the regexp matches.
Alex
diff --git a/Modules/FindZLIB.cmake b/Modules/FindZLIB.cmake
index ce29ca0..1ac6c2c 100644
--- a/Modules/FindZLIB.cmake
+++ b/Modules/FindZLIB.cmake
@@ -50,9 +50,14 @@ IF(ZLIB_INCLUDE_DIR AND EXISTS ${ZLIB_INCLUDE_DIR}/zlib.h)
STRING(REGEX REPLACE ^.*ZLIB_VERSION \([0-9]+).*$ \\1
ZLIB_VERSION_MAJOR ${ZLIB_H})
STRING(REGEX REPLACE ^.*ZLIB_VERSION \[0-9]+\\.([0-9]+).*$ \\1
ZLIB_VERSION_MINOR ${ZLIB_H})
STRING(REGEX REPLACE ^.*ZLIB_VERSION \[0-9]+\\.[0-9]+\\.([0-9]+).*$
\\1 ZLIB_VERSION_PATCH ${ZLIB_H})
-STRING(REGEX REPLACE ^.*ZLIB_VERSION
\[0-9]+\\.[0-9]+\\.[0-9]+\\.([0-9]+).*$ \\1 ZLIB_VERSION_TWEAK ${ZLIB_H})
+SET(ZLIB_VERSION_STRING
${ZLIB_VERSION_MAJOR}.${ZLIB_VERSION_MINOR}.${ZLIB_VERSION_PATCH})
-SET(ZLIB_VERSION_STRING
${ZLIB_VERSION_MAJOR}.${ZLIB_VERSION_MINOR}.${ZLIB_VERSION_PATCH}.${ZLIB_VERSION_TWEAK})
+# only append a TWEAK version if it exists:
+SET(ZLIB_VERSION_TWEAK )
+IF( ${ZLIB_H} MATCHES ^.*ZLIB_VERSION
\[0-9]+\\.[0-9]+\\.[0-9]+\\.([0-9]+).*$)
+SET(ZLIB_VERSION_TWEAK ${CMAKE_MATCH_1})
+SET(ZLIB_VERSION_STRING ${ZLIB_VERSION_STRING}.${ZLIB_VERSION_TWEAK})
+ENDIF( ${ZLIB_H} MATCHES ^.*ZLIB_VERSION
\[0-9]+\\.[0-9]+\\.[0-9]+\\.([0-9]+).*$)
SET(ZLIB_MAJOR_VERSION ${ZLIB_VERSION_MAJOR})
SET(ZLIB_MINOR_VERSION ${ZLIB_VERSION_MINOR})
---
Summary of changes:
Modules/FindZLIB.cmake |9 +++--
1 files changed, 7 insertions(+), 2 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.2-439-g5b60a4b
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 5b60a4b6c532de3aa2f354ee13d3b08f78b52c21 (commit)
via b173b879f8c2a3035d826e1cfa1407380b6eb2ee (commit)
from 69f80a94a3e132cfa0b009d6f2d030bb7e5de40d (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=5b60a4b6c532de3aa2f354ee13d3b08f78b52c21
commit 5b60a4b6c532de3aa2f354ee13d3b08f78b52c21
Merge: 69f80a9 b173b87
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Aug 14 22:23:45 2010 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Sat Aug 14 22:23:45 2010 +0200
Merge branch 'CMakeParseArguments' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b173b879f8c2a3035d826e1cfa1407380b6eb2ee
commit b173b879f8c2a3035d826e1cfa1407380b6eb2ee
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Aug 14 22:06:49 2010 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Sat Aug 14 22:06:49 2010 +0200
Add macro CMakeParseArguments() and use it in FPHSA()
This adds a macro cmake_parse_arguments() (as discussed on cmake-devel)
which can be used in macros or functions to help with parsing its
arguments. Detailled docs are included.
find_package_handle_standard_args() is the first user of this new macro.
Alex
diff --git a/Modules/CMakeParseArguments.cmake
b/Modules/CMakeParseArguments.cmake
new file mode 100644
index 000..c7148ae
--- /dev/null
+++ b/Modules/CMakeParseArguments.cmake
@@ -0,0 +1,137 @@
+# CMAKE_PARSE_ARGUMENTS(prefix options one_value_keywords
multi_value_keywords args...)
+#
+# CMAKE_PARSE_ARGUMENTS() is intended to be used in macros or functions for
+# parsing the arguments given to that macro or function.
+# It processes the arguments and defines a set of variables which hold the
+# values of the respective options.
+#
+# The options argument contains all options for the respective macro,
+# i.e. keywords which can be used when calling the macro without any value
+# following, like e.g. the OPTIONAL keyword of the install() command.
+#
+# The one_value_keywords argument contains all keywords for this macro
+# which are followed by one value, like e.g. DESTINATION keyword of the
+# install() command.
+#
+# The multi_value_keywords argument contains all keywords for this macro
+# which can be followed by more than one value, like e.g. the TARGETS or
+# FILES keywords of the install() command.
+#
+# When done, CMAKE_PARSE_ARGUMENTS() will have defined for each of the
+# keywords listed in options, one_value_keywords and
+# multi_value_keywords a variable composed of the given prefix
+# followed by _ and the name of the respective keyword.
+# These variables will then hold the respective value from the argument list.
+# For the options keywords this will be TRUE or FALSE.
+#
+# All remaining arguments are collected in a variable
+# prefix_UNPARSED_ARGUMENTS, this can be checked afterwards to see whether
+# your macro was called with unrecognized parameters.
+#
+# As an example here a my_install() macro, which takes similar arguments as the
+# real install() command:
+#
+# function(MY_INSTALL)
+# set(options OPTIONAL FAST)
+# set(oneValueArgs DESTINATION RENAME)
+# set(multiValueArgs TARGETS CONFIGURATIONS)
+# cmake_parse_arguments(MY_INSTALL ${options} ${oneValueArgs}
${multiValueArgs} ${ARGN} )
+# ...
+#
+# Assume my_install() has been called like this:
+# my_install(TARGETS foo bar DESTINATION bin OPTIONAL blub)
+#
+# After the cmake_parse_arguments() call the macro will have set the following
+# variables:
+# MY_INSTALL_OPTIONAL = TRUE
+# MY_INSTALL_FAST = FALSE (this option was not used when calling my_install()
+# MY_INSTALL_DESTINATION = bin
+# MY_INSTALL_RENAME = (was not used)
+# MY_INSTALL_TARGETS = foo;bar
+# MY_INSTALL_CONFIGURATIONS = (was not used)
+# MY_INSTALL_UNPARSED_ARGUMENTS = blub (no value expected after OPTIONAL
+#
+# You can the continue and process these variables.
+#
+# Keywords terminate lists of values, e.g. if directly after a
one_value_keyword
+# another recognized keyword follows, this is interpreted as the beginning of
+# the new option.
+# E.g. my_install(TARGETS foo DESTINATION OPTIONAL) would result in
+# MY_INSTALL_DESTINATION set to OPTIONAL, but MY_INSTALL_DESTINATION would
+# be empty and MY_INSTALL_OPTIONAL would be set to TRUE therefor.
+
+# Copyright (c) 2010, Alexander Neundorf, neund...@kde.org
+#
+# Distributed under the OSI-approved BSD License (the License);
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even
[Cmake-commits] CMake branch, master, updated. v2.8.2-210-gb0d03c9
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 b0d03c9953693137186dc17e20596752d1beb371 (commit) from 16168ab0c3549b6953fe95354446508ce3cc945e (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=b0d03c9953693137186dc17e20596752d1beb371 commit b0d03c9953693137186dc17e20596752d1beb371 Author: KWSys Robot kwro...@kitware.com AuthorDate: Sun Aug 15 00:01:07 2010 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sun Aug 15 00:10:03 2010 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 55aa1c8..f654dfa 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 08) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 14) +SET(KWSYS_DATE_STAMP_DAY 15) --- 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
