Re: [CMake] Questions about the cmake 2.8.3-rc1 release
Andrew, I was not advocating ANY "unlimited" access by otherwise unapproved users of your resources. What I am noting is that some of us do not have access to a sufficiently wide range of environments in order to develop code that "should be expected to work" within the "NEXT" protocol. I will point out that your willingness to run "CMake nightly" runs supporting Kitware is not really different, conceptually, from running "Development Trials" that I might create. In each case, you are "at risk" from any possible intrusions that might accompany submitted tests. I would hope that you are not placing anything more that "CPU cycles" at risk from abuse. What I am seeking is a mechanism to allow "testing" of code BEFORE it is considered ready for "next", etc. Perhaps this needs to be done on a limited "opt-in" basis. Your references to "Workflow" do not, within my quick reading, address the ability to provide testing on an increasing scale over OS, etc. before providing candidates into the more established flows. Richard On Sep 15, 2010, at 7:30 PM, Andrew Maclean wrote: > Hi All, > Speaking for my site regarding point 2, we would be unwilling to allow > general external access to our machines. I would suspect most other > sites would feel the same way. > > From my viewpoint the process as outlined in > http://www.cmake.org/Wiki/CMake/Git seems to work well. The workflow > as outlined in http://public.kitware.com/Wiki/Git/Workflow/Topic > allows you to work on your code and test it thoroughly before pushing. > When you push check the dashboard after a while to see if there are > any errors. The 'next' branch is reported on the dashboards (the last > time I looked). At some stage, Kitware will merge next into master. > So I guess next is a kind of sandbox. In this situation, the master > sees only the topics that have been merged into it, It cannot reach > any of the merges into next, so master should remain quite stable. > > I hope this helps. > > Regards > Andrew > > On Thu, Sep 16, 2010 at 9:26 AM, Richard Wackerbarth > wrote: >> Bill, >> >> Some observations on "Dashboard Builds": >> >> As you know, I run a number of FreeBSD builds on the "Nightly" branch. >> I had not been running "2.8" builds, etc. because it was unclear if my >> builds would be of any real value, but only consume my CPU time and increase >> my electric bill without providing additional information. >> >> My builds are all done on "minimal" installations as an adjunct to my own >> regression testing. In some respects, they may not represent, and therefore >> not test, typical end-user environments. >> >> If adding builds for the 2.8 branch would be of real value, rather than just >> a waste of my resources, please let me know. >> >> As a "dimension" of builds, it appears to me that the conversion to "git" >> creates an opportunity to treat all builds in a manner analogous to the >> "continuous" builds. There, with some minimum wait time, we test to see if >> anything has changed (in "git" this is a trivial test to see if the branch >> reference has changed) and run the test suite only if there has been a >> change. >> >> We could treat "nightly" in the same manner. The "nightly" branch would be >> thus modified, only by the cron robot, once every 24 hours. The clients, >> with little overhead, might check for changes every 5 minutes, or every 24 >> hours, or anywhere in between. >> >> Similarly, the "release candidate" branch might not change for weeks at a >> time. But for each change, and only upon a change, the clients would "give >> it a try" without wasting time re-running the test suite on an unchanged >> source set. >> >> A third topic: >> >> I have been spending some time looking at the issues behind my open "bug" >> (9825) and have concluded that I could, and to some extent did, write code >> for the FreeBSD branch that would "work", but concluded that it would be >> more of a "wart" than a "fix". >> IMHO, to do it right, the CMake code involved should be re-factored so that >> the best identification strategies can be applied to each, and every, >> platform. For example, if the "cupid" instructions can be accessed on Intel >> platforms, EVERY OS should utilize it and use a common decode routine to >> access the data there available. I am capable of writing such code. However, >> I do not have the resources to test my code on platforms other that MacOS >> and FreeBSD. >> >> I would like to suggest that you consider making available access to >> additional platforms by: >> (1) Finding a representative set of machines, of various configurations and >> OS, willing to run test suites for development support. >> (2) Establishing a mechanism to approve "sandboxes" for the development of a >> particular idea. I'm sure that you already do this, internally, to some >> extent. But, I am advocating extending it to external developers and >> external machine resources (as nee
Re: [CMake] build priority
On 09/16/2010 02:27 AM, Serghei Amelian wrote: > Hi, > > Is any way to tell cmake to build a target before beginning to start > compiling > another one? For example, i need target "dcopidl" to be exists before > generating *.kidl files. Use ADD_DEPENDENCIES() and the DEPENDS option of custom targets/commands. 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] Questions about the cmake 2.8.3-rc1 release
Hi All, Speaking for my site regarding point 2, we would be unwilling to allow general external access to our machines. I would suspect most other sites would feel the same way. >From my viewpoint the process as outlined in http://www.cmake.org/Wiki/CMake/Git seems to work well. The workflow as outlined in http://public.kitware.com/Wiki/Git/Workflow/Topic allows you to work on your code and test it thoroughly before pushing. When you push check the dashboard after a while to see if there are any errors. The 'next' branch is reported on the dashboards (the last time I looked). At some stage, Kitware will merge next into master. So I guess next is a kind of sandbox. In this situation, the master sees only the topics that have been merged into it, It cannot reach any of the merges into next, so master should remain quite stable. I hope this helps. Regards Andrew On Thu, Sep 16, 2010 at 9:26 AM, Richard Wackerbarth wrote: > Bill, > > Some observations on "Dashboard Builds": > > As you know, I run a number of FreeBSD builds on the "Nightly" branch. > I had not been running "2.8" builds, etc. because it was unclear if my builds > would be of any real value, but only consume my CPU time and increase my > electric bill without providing additional information. > > My builds are all done on "minimal" installations as an adjunct to my own > regression testing. In some respects, they may not represent, and therefore > not test, typical end-user environments. > > If adding builds for the 2.8 branch would be of real value, rather than just > a waste of my resources, please let me know. > > As a "dimension" of builds, it appears to me that the conversion to "git" > creates an opportunity to treat all builds in a manner analogous to the > "continuous" builds. There, with some minimum wait time, we test to see if > anything has changed (in "git" this is a trivial test to see if the branch > reference has changed) and run the test suite only if there has been a change. > > We could treat "nightly" in the same manner. The "nightly" branch would be > thus modified, only by the cron robot, once every 24 hours. The clients, with > little overhead, might check for changes every 5 minutes, or every 24 hours, > or anywhere in between. > > Similarly, the "release candidate" branch might not change for weeks at a > time. But for each change, and only upon a change, the clients would "give it > a try" without wasting time re-running the test suite on an unchanged source > set. > > A third topic: > > I have been spending some time looking at the issues behind my open "bug" > (9825) and have concluded that I could, and to some extent did, write code > for the FreeBSD branch that would "work", but concluded that it would be more > of a "wart" than a "fix". > IMHO, to do it right, the CMake code involved should be re-factored so that > the best identification strategies can be applied to each, and every, > platform. For example, if the "cupid" instructions can be accessed on Intel > platforms, EVERY OS should utilize it and use a common decode routine to > access the data there available. I am capable of writing such code. However, > I do not have the resources to test my code on platforms other that MacOS and > FreeBSD. > > I would like to suggest that you consider making available access to > additional platforms by: > (1) Finding a representative set of machines, of various configurations and > OS, willing to run test suites for development support. > (2) Establishing a mechanism to approve "sandboxes" for the development of a > particular idea. I'm sure that you already do this, internally, to some > extent. But, I am advocating extending it to external developers and external > machine resources (as needed). The idea is to have the testing resources of a > wide variety of machines available without the requirement that the code meet > the expectations associated with "ready for public trial". Then, when it is > ready, the code. so developed, can be submitted to "next" for a through > evaluation. > > Richard > > On Sep 15, 2010, at 4:34 PM, Bill Hoffman wrote: > >> On 9/15/2010 4:20 PM, Bill Hoffman wrote: >>> On 9/15/2010 4:08 PM, norulez wrote: Are there any hopes that the bug 4068 is fixed in the final release? If not, then in which version? > >>> Not at this point. The bug report lacks a test cases. If you were to add >>> a test case, and join the cmake-developer mailing list. Then you can >>> make sure it ends up in the next branch now, so that it can be in the >>> next official release. We are doing releases each quarter, but at this >>> point if it is not a regression and has not been tested in the "next" >>> branch of CMake, it will not be in 2.8.3. > ___ > 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] build priority
Hi, Is any way to tell cmake to build a target before beginning to start compiling another one? For example, i need target "dcopidl" to be exists before generating *.kidl files. Thanks -- Serghei ___ 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] CPU identification
CTest, when submitting a dashboard, apparently has the ability to introspect quite a lot of information about the system it is running on, such as the number of CPU cores and so on. Is it possible to get this information in a cmake or ctest script? I see eg. CMAKE_HOST_SYSTEM_PROCESSOR in the docs, but those variables are somewhat more generic about the platform and OS, not the hardware. My particular goal is to automatically provide the right -j option for maximizing parallel build performance, but know how to find all the other information CTest can get may well be useful in future as well. Ceej aka Chris Hillery ___ 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] Questions about the cmake 2.8.3-rc1 release
Bill, Some observations on "Dashboard Builds": As you know, I run a number of FreeBSD builds on the "Nightly" branch. I had not been running "2.8" builds, etc. because it was unclear if my builds would be of any real value, but only consume my CPU time and increase my electric bill without providing additional information. My builds are all done on "minimal" installations as an adjunct to my own regression testing. In some respects, they may not represent, and therefore not test, typical end-user environments. If adding builds for the 2.8 branch would be of real value, rather than just a waste of my resources, please let me know. As a "dimension" of builds, it appears to me that the conversion to "git" creates an opportunity to treat all builds in a manner analogous to the "continuous" builds. There, with some minimum wait time, we test to see if anything has changed (in "git" this is a trivial test to see if the branch reference has changed) and run the test suite only if there has been a change. We could treat "nightly" in the same manner. The "nightly" branch would be thus modified, only by the cron robot, once every 24 hours. The clients, with little overhead, might check for changes every 5 minutes, or every 24 hours, or anywhere in between. Similarly, the "release candidate" branch might not change for weeks at a time. But for each change, and only upon a change, the clients would "give it a try" without wasting time re-running the test suite on an unchanged source set. A third topic: I have been spending some time looking at the issues behind my open "bug" (9825) and have concluded that I could, and to some extent did, write code for the FreeBSD branch that would "work", but concluded that it would be more of a "wart" than a "fix". IMHO, to do it right, the CMake code involved should be re-factored so that the best identification strategies can be applied to each, and every, platform. For example, if the "cupid" instructions can be accessed on Intel platforms, EVERY OS should utilize it and use a common decode routine to access the data there available. I am capable of writing such code. However, I do not have the resources to test my code on platforms other that MacOS and FreeBSD. I would like to suggest that you consider making available access to additional platforms by: (1) Finding a representative set of machines, of various configurations and OS, willing to run test suites for development support. (2) Establishing a mechanism to approve "sandboxes" for the development of a particular idea. I'm sure that you already do this, internally, to some extent. But, I am advocating extending it to external developers and external machine resources (as needed). The idea is to have the testing resources of a wide variety of machines available without the requirement that the code meet the expectations associated with "ready for public trial". Then, when it is ready, the code. so developed, can be submitted to "next" for a through evaluation. Richard On Sep 15, 2010, at 4:34 PM, Bill Hoffman wrote: > On 9/15/2010 4:20 PM, Bill Hoffman wrote: >> On 9/15/2010 4:08 PM, norulez wrote: >>> Are there any hopes that the bug 4068 is fixed in the final release? >>> If not, then in which version? >> Not at this point. The bug report lacks a test cases. If you were to add >> a test case, and join the cmake-developer mailing list. Then you can >> make sure it ends up in the next branch now, so that it can be in the >> next official release. We are doing releases each quarter, but at this >> point if it is not a regression and has not been tested in the "next" >> branch of CMake, it will not be in 2.8.3. ___ 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] Questions about the cmake 2.8.3-rc1 release
On 9/15/2010 4:20 PM, Bill Hoffman wrote: On 9/15/2010 4:08 PM, norulez wrote: Hello, are there any hopes that the bug 4068 is fixed in the final release? If not, then in which version? Not at this point. The bug report lacks a test cases. If you were to add a test case, and join the cmake-developer mailing list. Then you can make sure it ends up in the next branch now, so that it can be in the next official release. We are doing releases each quarter, but at this point if it is not a regression and has not been tested in the "next" branch of CMake, it will not be in 2.8.3. The CMake developers list can be found here: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I will update the web page soon. -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
Re: [CMake] NO_SOURCE_PERMISSIONS has no effect on FILE(INSTALL ...)
On 09/16/2010 12:09 AM, Angel Tsankov wrote: Why does FILE(INSTALL ...) try to set permissions on destination files even when I pass NO_SOURCE_PERMISSIONS? This happens when installing a directory: FILE(INSTALL "dir" DESTINATION "/usr/share/icons/oxygen" NO_SOURCE_PERMISSIONS) Is it possible to skip setting any permissions when installing a directory that already exists at the destination? Regards, Angel Tsankov ___ 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] NO_SOURCE_PERMISSIONS has no effect on FILE(INSTALL ...)
Why does FILE(INSTALL ...) try to set permissions on destination files even when I pass NO_SOURCE_PERMISSIONS? Best regards, Angel Tsankov ___ 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] Questions about the cmake 2.8.3-rc1 release
On 9/15/2010 4:08 PM, norulez wrote: Hello, are there any hopes that the bug 4068 is fixed in the final release? If not, then in which version? Not at this point. The bug report lacks a test cases. If you were to add a test case, and join the cmake-developer mailing list. Then you can make sure it ends up in the next branch now, so that it can be in the next official release. We are doing releases each quarter, but at this point if it is not a regression and has not been tested in the "next" branch of CMake, it will not be in 2.8.3. Thanks. -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
Re: [CMake] add_dependency on a custom target
On 09/15/2010 05:15 PM, Nick Davidson wrote:
> Whoops, forgot to reply on list, sorry!
>
>> From: cmake-boun...@cmake.org
>> [mailto:cmake-boun...@cmake.org] On Behalf Of Andreas Pakulat
>> Sent: 15 September 2010 13:03
>> To: cmake@cmake.org
>> Subject: Re: [CMake] add_dependency on a custom target
>>
>> On 15.09.10 12:34:43, Nick Davidson wrote:
>>> Dear List,
>>>
>>> I'm using a file glob to extract a list of xml files to pass to a
>>> custom target to generate a pot file with getttext, most of
>> the heavy
>>> lifting is handled by a Macro.
>>>
>>> include(FindMsgfmt)
>>> macro (MakePot BIN_NAME CPP_SOURCES XML_SOURCES)
>>> set(CPP_SRCS ${CPP_SOURCES})
>>> set(XML_SRCS ${XML_SOURCES})
>>> set(POT_FILE ${BIN_NAME}.pot)
>>> if (XGETTEXT_FOUND)
>>> message(STATUS "Adding Target Potfile: ${POT_FILE}")
>>> if (XML_SRCS)
>>> add_custom_target(${POT_FILE} ALL
>>> COMMAND ${XGETTEXT_EXECUTABLE} --language=C++
>> --force-po
>>> -kN_ -kNN_:1,2 -o ${POT_FILE} ${CPP_SRCS}
>>> COMMAND ${XGETTEXT_EXECUTABLE} --language=Glade
>>> --force-po -j -o ${POT_FILE} ${XML_SRCS} )
>>> else (XML_SRCS)
>> add_custom_target(${POT_FILE} ALL
>>> COMMAND ${XGETTEXT_EXECUTABLE} --language=C++
>> --force-po
>>> -kN_ -kNN_:1,2 -o ${POT_FILE} ${CPP_SRCS})
>>> endif(XML_SRCS)
>>> add_dependencies(${POT_FILE} ${XML_SOURCES} ${CPP_SRCS})
>>> else (XGETTEXT_FOUND)
>>> message(STATUS "Cannot find xgettext")
>>> endif(XGETTEXT_FOUND)
>>> endmacro (MakePot POT_NAME)
>>>
>>> The only problem is, if the list of xml files changes (e.g. a
>>> deletion) the cmake cache doesn't get regenerated and thus the xml
>>> files are not reglobbed and so the custom command fails.
>>>
>>> Any suggestions?
>>
>> Don't use a glob (list the files individually) or remember to touch
>> the cmakelists.txt file after adding new files. I don't think there's
>> a way to have cmake re-run when calling just make within
>> cmakelists.txt.
>
> Ok, but why doesn't adding the files as dependencies work?
> The glob is stored in the cache - fine, there isn't a way for Cmake to
> automatically figure out what files it should check to see if anything
> has changed. Having added those files as dependencies of the target that
> uses the glob manually then surely it's just a list of files?
>
>
> Is there a fundamental difference between a list variable made from
> a globbed set of files and a list made from a manually specified set?
Don't use ADD_DEPENDENCIES() to establish a dependency of a target on
files; it's for target interdependencies only. Furthermore, you don't
need a dependency of a custom target on your XML files unless they're
generated by a custom command; custom targets are always out of date
and, thus, rebuilt when they are checked. So, when (re)building, the
target associated with the POT_FILE is (re)built anyway, but at the
moment, it works on the files collected once at configuration time.
However, you can delay the files' collection till build time:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GLOB NONE)
FILE(WRITE ${CMAKE_BINARY_DIR}/glob.cmake "
FILE(GLOB_RECURSE g *.cmake)
EXECUTE_PROCESS(COMMAND echo \"xgettext ...\" \${g})
")
ADD_CUSTOM_TARGET(glob ALL
${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/glob.cmake
)
The glob.cmake script is invoked by a custom target at build time,
collects the files and executes a command on them, so there is no
need to reconfigure after the set of collected files has changed.
BTW, wouldn't it be more appropriate to use a custom command for
the pot files' generation?
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
[CMake] Questions about the cmake 2.8.3-rc1 release
Hello, are there any hopes that the bug 4068 is fixed in the final release? If not, then in which version? Thanks in advance Best Regards NoRulez ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindLibrary only looks for lib under Windows
> Am Wednesday 15 September 2010 schrieb David Cole: >> find_library always looks for *.lib files on Windows. Those are the ones >> that need to be passed to the linker. The *.dll files are the ones that >> need to be there at runtime in order to run correctly. >> >> This behavior is intended, by design, and is working correctly. > > IIRC at least newer versions of MinGW can link directly against dll's. > MinGW can do this however all versions of Visual Studio require an import library. In VS linking to the .lib is necessary even though the executable code is in the .dlls 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] FindLibrary only looks for lib under Windows
Am Wednesday 15 September 2010 schrieb David Cole: > find_library always looks for *.lib files on Windows. Those are the ones > that need to be passed to the linker. The *.dll files are the ones that > need to be there at runtime in order to run correctly. > > This behavior is intended, by design, and is working correctly. IIRC at least newer versions of MinGW can link directly against dll's. Eike signature.asc Description: This is a digitally signed message part. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 2.8.3-rc1 ready for testing!
I am happy to announce that CMake 2.8.3 has entered the release candidate stage! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Following is the list of changes in this release. (If you notice something missing please let me know and I will add it to the official release when 2.8.3 is finalized.) Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Happy building! -Dave Changes in CMake 2.8.3-rc1 (since 2.8.2) Alex Neundorf (39): fix build on SUSE 11.2 in cmcurl due to ssize_t -add an additional name for finding libtiff on Windows -fix typo in docs of deprecated MacroAddFileDependencies.cmake add 2nd, more powerful mode to find_package_handle_standard_args() -fix indentation of the documentation Add version checking support to FindFlex and FindPerlLibs FindSquish doesn't detect the version, remove that from the documentation Improved version checking for FindRuby using the new mode of FPHSA() Improved version checking for FindJava using the new FPHSA() mode Fix DETAILS string with version number in FHPSA() Improved version checking for FindSubversion using the new mode of FPHSA() Improved version checking for FindCUDA using the new mode of FPHSA Use FPHSA() in FindSWIG, including version checking. Change documentation of Subversion_FOUND and SUBVERSION_FOUND. Add macro CMakeParseArguments() and use it in FPHSA() Fix ZLIB version parsing if no TWEAK version exists Fix EclipseCDT include path parsing with spaces (#10868) Fix EclipseCDT parsing of builtin macros with spaces (#10868) Remove trailing spaces Detect a COMPILER_ID also for ASM. Add timeout to execute_process() in CMAKE_DETERMINE_COMPILER_ID(). Fix parsing of builtin macros so Eclipse handles them properly (#10868) Log the required package version and major improvement to FeatureSummary Improve documentation. Improve wording of the documentation. Add macro ADD_FEATURE_INFO() and improve docs. Remove trailing whitespace Make target_link_libraries() complain if bad target name is used Just warn in case of a bad target as only argument for t_l_l() Remove trailing whitespace New CMP0016 for deciding whether an unknown target in TLL() is an error. Record all considered Config files and their versions. Improve error message in Config-mode when no appropriate version was found Replace the two vector with one vector Small cleanup of FindPackageHandleStandardArgs.cmake Don't create an empty element at the end of Foo_CONSIDERED_CONFIGS/VERSIONS Add option CONFIG_MODE to FPHSA() Improve version notice in the generated message Improve wording of the error message of find_package() in config-mode Andrew Maclean (3): Adding a FindPostgreSQL.cmake module Forgot the copyright notice. Changed ADDITIONAL_SEARCH_PATHS to PostgreSQL_ADDITIONAL_SEARCH_PATHS. Arjen Verweij (1): Pass objects to Intel linker using a response file Bill Hoffman (9): Disable gcc 33 on OpenBSD because it crashes CPack by default. Fix for bug#10483, INCLUDE_EXTERNAL_MSPROJECT: ProjectGUID now ProjectGuid Remove the ctest submit larget output test. Let CMake recognize .CPP .CXX and .C++ as c++ files. Fix for bug 10388, fix various default flags. Only use .CPP .CXX and .C++ do not work by default with g+++. Fix targets with . in the name for VS 10 IDE. Only test for .CPP on Microsoft compilers which will handle .CPP as c++. Allow testing of .CPP on WIN32 as it is a case insensitive OS and should work. Brad King (69): ExternalProject: Add LOG_* options to hide step output FindMPI: Do not parse -l in middle of library name FindMPI: Parse mpicc flags more carefully (#9093) Fix or cast integer conversions in cmake Begin post-2.8.2 development FindMPI: Failure is not an error if not REQUIRED FindMPI: Trust mpicc -showme on BlueGene/L VS: Always separate preprocessor defs by semicolon (#10902) KWSys: Cleanup putenv leak option implementation KWSys: Pass ptrdiff_t check result to System.c Fix or cast more integer conversions in cmake Use same type in both cases of '?:' operator FindMPI: Fix parsing of mpicc -Wl,-L link flags (#9093) Fix signed/unsigned comparison warnings in ccmake Fix integer conversions in cpack bootstrap: Detect known C/C++ compiler toolchains KWSys: Use short fallback timeout for Process tests KWSys: Optionally suppress consistent test failures KWSys: Avoid Clang optimizer bug in testProcess-[45] Poison GCC 3.3 on OpenBSD a bit later KWSys: Avoid undefined behavior in Process crash tests Optionally use system
Re: [CMake] add_dependency on a custom target
On Wed, Sep 15, 2010 at 11:15 AM, Nick Davidson wrote:
> Whoops, forgot to reply on list, sorry!
>
> > From: cmake-boun...@cmake.org
> > [mailto:cmake-boun...@cmake.org] On Behalf Of Andreas Pakulat
> > Sent: 15 September 2010 13:03
> > To: cmake@cmake.org
> > Subject: Re: [CMake] add_dependency on a custom target
> >
> > On 15.09.10 12:34:43, Nick Davidson wrote:
> > > Dear List,
> > >
> > > I'm using a file glob to extract a list of xml files to pass to a
> > > custom target to generate a pot file with getttext, most of
> > the heavy
> > > lifting is handled by a Macro.
> > >
> > > include(FindMsgfmt)
> > > macro (MakePot BIN_NAME CPP_SOURCES XML_SOURCES)
> > > set(CPP_SRCS ${CPP_SOURCES})
> > > set(XML_SRCS ${XML_SOURCES})
> > > set(POT_FILE ${BIN_NAME}.pot)
> > > if (XGETTEXT_FOUND)
> > > message(STATUS "Adding Target Potfile: ${POT_FILE}")
> > > if (XML_SRCS)
> > > add_custom_target(${POT_FILE} ALL
> > > COMMAND ${XGETTEXT_EXECUTABLE} --language=C++
> > --force-po
> > > -kN_ -kNN_:1,2 -o ${POT_FILE} ${CPP_SRCS}
> > > COMMAND ${XGETTEXT_EXECUTABLE} --language=Glade
> > > --force-po -j -o ${POT_FILE} ${XML_SRCS} )
> > > else (XML_SRCS)
> > add_custom_target(${POT_FILE} ALL
> > > COMMAND ${XGETTEXT_EXECUTABLE} --language=C++
> > --force-po
> > > -kN_ -kNN_:1,2 -o ${POT_FILE} ${CPP_SRCS})
> > > endif(XML_SRCS)
> > > add_dependencies(${POT_FILE} ${XML_SOURCES} ${CPP_SRCS})
> > > else (XGETTEXT_FOUND)
> > > message(STATUS "Cannot find xgettext")
> > > endif(XGETTEXT_FOUND)
> > > endmacro (MakePot POT_NAME)
> > >
> > > The only problem is, if the list of xml files changes (e.g. a
> > > deletion) the cmake cache doesn't get regenerated and thus the xml
> > > files are not reglobbed and so the custom command fails.
> > >
> > > Any suggestions?
> >
> > Don't use a glob (list the files individually) or remember to touch
> > the cmakelists.txt file after adding new files. I don't think there's
> > a way to have cmake re-run when calling just make within
> > cmakelists.txt.
>
> Ok, but why doesn't adding the files as dependencies work?
> The glob is stored in the cache - fine, there isn't a way for Cmake to
> automatically figure out what files it should check to see if anything
> has changed. Having added those files as dependencies of the target that
> uses the glob manually then surely it's just a list of files?
>
>
> Is there a fundamental difference between a list variable made from
> a globbed set of files and a list made from a manually specified set?
>
There's no indication that a set of files retrieved by glob has changed when
a file is added or removed from a directory. So if the set changes, neither
make nor cmake know that anything is out of date... and nothing re-runs.
The mod time of the file containing the list changes when the manually
specified list changes. Therefore CMake can be re-run by make.
>
> >
> > Andreas
> >
> > --
>
> Nickd
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake -E compare_files - end of line character
It would be nice if compare_files did this, but really this is a problem that should be handled by your source-control system, I think. Subversion, for example, will ensure that text files are checked out with locally-appropriate line endings, at least if you ask it nicely. I'm pretty sure the same is true of Perforce and probably other systems. Ceej aka Chris Hillery On Wed, Sep 15, 2010 at 1:40 AM, Olivier Pierard wrote: > Dear all, > > For several testcases validations, I use 'cmake -E compare_files' > command on a result file against a reference file. Problem is that > result file might be generated on several different platforms while > reference file is the same for all platforms. Unfortunately, there is > no option in cmake -E compare_files to ignore end of line characters on > the contrary to diff, winmerge,... The current solution is to call an > 'home-made' unix2dos C++ function or call a configure_file() command to > set correctly eol accoreding to the platform for the reference file so > that compare_files gives the correct answer. > > Is there a way to avoid this 'stupid' solution ? Is it useful to submit > a development request for this feature ? > > Thanks for your help, > > Olivier > > ___ > 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] add_dependency on a custom target
Whoops, forgot to reply on list, sorry!
> From: cmake-boun...@cmake.org
> [mailto:cmake-boun...@cmake.org] On Behalf Of Andreas Pakulat
> Sent: 15 September 2010 13:03
> To: cmake@cmake.org
> Subject: Re: [CMake] add_dependency on a custom target
>
> On 15.09.10 12:34:43, Nick Davidson wrote:
> > Dear List,
> >
> > I'm using a file glob to extract a list of xml files to pass to a
> > custom target to generate a pot file with getttext, most of
> the heavy
> > lifting is handled by a Macro.
> >
> > include(FindMsgfmt)
> > macro (MakePot BIN_NAME CPP_SOURCES XML_SOURCES)
> > set(CPP_SRCS ${CPP_SOURCES})
> > set(XML_SRCS ${XML_SOURCES})
> > set(POT_FILE ${BIN_NAME}.pot)
> > if (XGETTEXT_FOUND)
> > message(STATUS "Adding Target Potfile: ${POT_FILE}")
> > if (XML_SRCS)
> > add_custom_target(${POT_FILE} ALL
> > COMMAND ${XGETTEXT_EXECUTABLE} --language=C++
> --force-po
> > -kN_ -kNN_:1,2 -o ${POT_FILE} ${CPP_SRCS}
> > COMMAND ${XGETTEXT_EXECUTABLE} --language=Glade
> > --force-po -j -o ${POT_FILE} ${XML_SRCS} )
> > else (XML_SRCS)
> add_custom_target(${POT_FILE} ALL
> > COMMAND ${XGETTEXT_EXECUTABLE} --language=C++
> --force-po
> > -kN_ -kNN_:1,2 -o ${POT_FILE} ${CPP_SRCS})
> > endif(XML_SRCS)
> > add_dependencies(${POT_FILE} ${XML_SOURCES} ${CPP_SRCS})
> > else (XGETTEXT_FOUND)
> > message(STATUS "Cannot find xgettext")
> > endif(XGETTEXT_FOUND)
> > endmacro (MakePot POT_NAME)
> >
> > The only problem is, if the list of xml files changes (e.g. a
> > deletion) the cmake cache doesn't get regenerated and thus the xml
> > files are not reglobbed and so the custom command fails.
> >
> > Any suggestions?
>
> Don't use a glob (list the files individually) or remember to touch
> the cmakelists.txt file after adding new files. I don't think there's
> a way to have cmake re-run when calling just make within
> cmakelists.txt.
Ok, but why doesn't adding the files as dependencies work?
The glob is stored in the cache - fine, there isn't a way for Cmake to
automatically figure out what files it should check to see if anything
has changed. Having added those files as dependencies of the target that
uses the glob manually then surely it's just a list of files?
Is there a fundamental difference between a list variable made from
a globbed set of files and a list made from a manually specified set?
>
> Andreas
>
> --
Nickd
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
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] add_dependency on a custom target
On 15.09.10 12:34:43, Nick Davidson wrote:
> Dear List,
>
> I'm using a file glob to extract a list of xml files to pass to a custom
> target to generate
> a pot file with getttext, most of the heavy lifting is handled by a
> Macro.
>
> include(FindMsgfmt)
> macro (MakePot BIN_NAME CPP_SOURCES XML_SOURCES)
> set(CPP_SRCS ${CPP_SOURCES})
> set(XML_SRCS ${XML_SOURCES})
> set(POT_FILE ${BIN_NAME}.pot)
> if (XGETTEXT_FOUND)
> message(STATUS "Adding Target Potfile: ${POT_FILE}")
> if (XML_SRCS)
> add_custom_target(${POT_FILE} ALL
> COMMAND ${XGETTEXT_EXECUTABLE} --language=C++ --force-po
> -kN_ -kNN_:1,2 -o
> ${POT_FILE} ${CPP_SRCS}
> COMMAND ${XGETTEXT_EXECUTABLE} --language=Glade --force-po
> -j -o
> ${POT_FILE} ${XML_SRCS} )
> else (XML_SRCS) add_custom_target(${POT_FILE} ALL
> COMMAND ${XGETTEXT_EXECUTABLE} --language=C++ --force-po
> -kN_ -kNN_:1,2 -o
> ${POT_FILE} ${CPP_SRCS})
> endif(XML_SRCS)
> add_dependencies(${POT_FILE} ${XML_SOURCES} ${CPP_SRCS})
> else (XGETTEXT_FOUND)
> message(STATUS "Cannot find xgettext")
> endif(XGETTEXT_FOUND)
> endmacro (MakePot POT_NAME)
>
> The only problem is, if the list of xml files changes (e.g. a deletion)
> the cmake
> cache doesn't get regenerated and thus the xml files are not reglobbed
> and so the
> custom command fails.
>
> Any suggestions?
Don't use a glob (list the files individually) or remember to touch the
cmakelists.txt file after adding new files. I don't think there's a way to
have cmake re-run when calling just make within cmakelists.txt.
Andreas
--
You will be imprisoned for contributing your time and skill to a bank robbery.
___
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] add_dependency on a custom target
Dear List,
I'm using a file glob to extract a list of xml files to pass to a custom
target to generate
a pot file with getttext, most of the heavy lifting is handled by a
Macro.
include(FindMsgfmt)
macro (MakePot BIN_NAME CPP_SOURCES XML_SOURCES)
set(CPP_SRCS ${CPP_SOURCES})
set(XML_SRCS ${XML_SOURCES})
set(POT_FILE ${BIN_NAME}.pot)
if (XGETTEXT_FOUND)
message(STATUS "Adding Target Potfile: ${POT_FILE}")
if (XML_SRCS)
add_custom_target(${POT_FILE} ALL
COMMAND ${XGETTEXT_EXECUTABLE} --language=C++ --force-po
-kN_ -kNN_:1,2 -o
${POT_FILE} ${CPP_SRCS}
COMMAND ${XGETTEXT_EXECUTABLE} --language=Glade --force-po
-j -o
${POT_FILE} ${XML_SRCS} )
else (XML_SRCS) add_custom_target(${POT_FILE} ALL
COMMAND ${XGETTEXT_EXECUTABLE} --language=C++ --force-po
-kN_ -kNN_:1,2 -o
${POT_FILE} ${CPP_SRCS})
endif(XML_SRCS)
add_dependencies(${POT_FILE} ${XML_SOURCES} ${CPP_SRCS})
else (XGETTEXT_FOUND)
message(STATUS "Cannot find xgettext")
endif(XGETTEXT_FOUND)
endmacro (MakePot POT_NAME)
The only problem is, if the list of xml files changes (e.g. a deletion)
the cmake
cache doesn't get regenerated and thus the xml files are not reglobbed
and so the
custom command fails.
Any suggestions?
Thanks,
Nick Davidson
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
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] FindLibrary only looks for lib under Windows
find_library always looks for *.lib files on Windows. Those are the ones
that need to be passed to the linker. The *.dll files are the ones that need
to be there at runtime in order to run correctly.
This behavior is intended, by design, and is working correctly.
HTH,
David
On Tue, Sep 14, 2010 at 10:17 PM, emeplease wrote:
> Hi, I have modified the FindAPR.cmake module to look for the APR library
> under Windows.
>
> Using Find_Library ,
> the library that it should look for is "libapr-1.dll" , however, cmake
> fails to find it. If I change the name from "libapr-1.dll" to
> "libapr-1.lib" , CMake can successfully locate it.
>
> I am using CMake 2.8 with Visual Studio Express 2008
>
>
> The structure is like
>
>
>
> IF(WIN32)
> SET(APR_INCLUDE_SEARCH_PATH ${CMAKE_SOURCE_DIR}/
> SET(APR_LIB_SEARCH_PATH ${CMAKE_SOURCE_DIR}/...
> ELSE(WIN32)
>
> ENDIF(WIN32)
>
>
>
>
> It then looks for the library by
>
> FIND_LIBRARY( APR_LIBRARY NAMES ${APR_NAMES} PATHS ${APR_LIB_SEARCH_PATH} )
>
>
>
>
> Many thanks
> 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
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake -E compare_files - end of line character
Dear all, For several testcases validations, I use 'cmake -E compare_files' command on a result file against a reference file. Problem is that result file might be generated on several different platforms while reference file is the same for all platforms. Unfortunately, there is no option in cmake -E compare_files to ignore end of line characters on the contrary to diff, winmerge,... The current solution is to call an 'home-made' unix2dos C++ function or call a configure_file() command to set correctly eol accoreding to the platform for the reference file so that compare_files gives the correct answer. Is there a way to avoid this 'stupid' solution ? Is it useful to submit a development request for this feature ? Thanks for your help, Olivier ___ 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
