On Thu, Jun 28, 2012 at 8:04 AM, Eric Noulard <[email protected]> wrote: > 2012/6/27 David Cole <[email protected]>: >> On Tue, Jun 26, 2012 at 6:31 PM, David Cole <[email protected]> wrote: >>> On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard <[email protected]> >>> wrote: >>>> 2012/6/26 Bill Hoffman <[email protected]>: >>>>> So, this code here: >>>>> >>>>> 2a34b579 Tests/CMakeLists.txt (Eric NOULARD 2012-03-30 >>>>> 17:07:06 +0200 720) # Analyze 'cpack --help' output for list of >>>>> available generators: >>>>> 2a34b579 Tests/CMakeLists.txt (Eric NOULARD 2012-03-30 >>>>> 17:07:06 +0200 721) execute_process(COMMAND ${CMAKE_CPACK_COMMAND} >>>>> --help >>>>> >>>>> >>>>> The trouble is the cpack that is being tested is the one from the build >>>>> tree. If you have a very old CMake build tree, and you do a git pull and >>>>> gets lots of new cmake code. Then when you re-run cmake on the build >>>>> tree, >>>>> the cpack --help might crash. I am not sure how this works on a fresh >>>>> build tree either as cpack won't even exist. >>>> >>>> You are right this kind of tests may not be safely done at CMake time. >>>> I did that in order to avoid to replicate the code inside CPack factory >>>> (have a look at cmCPackDebGenerator::CanGenerate() >>>> and cmCPackRPMGenerator::CanGenerate()) >>>> which checks whether if a generator may be instantiated or not. >>>> This was done for conditionnally enabling RPM or DEB generator on MacOS >>>> see http://public.kitware.com/Bug/view.php?id=13064 >>>> >>>> This is was mistake to do that in Tests/CMakeLists.txt. >>>> This should be harmless since it will probably "only" prevent RPM and DEB >>>> CPack tests to be run (ACTIVE_CPACK_GENERATORS will be empty) >>>> but this is a mistake. >>>> >>>> I shall implement proper CMake-time check in Tests/CMakeLists.txt. >>>> Unfortunately I may not be able to do that until sunday 1rst of July... >>>> >>>> Is this blocking 2.8.9 ? >>>> >>>> I'll try tomorrow night but I cannot ensure I'll have time to do it. >>>> >>>> Basically this would be something like: >>>> set(ACTIVE_CPACK_GENERATORS) >>>> then >>>> find_program(RPMBUILD_EXECUTABLE NAMES rpmbuild) >>>> if (RPMBUILD_EXECUTABLE) >>>> list(APPEND ACTIVE_CPACK_GENERATORS "RPM") >>>> endif() >>>> >>>> find_program(DPKG_EXECUTABLE NAMES dpkg) >>>> if (DPKG_EXECUTABLE) >>>> list(APPEND ACTIVE_CPACK_GENERATORS "DEB") >>>> endif() >>>> >>>> >>>> -- >>>> Erk >>>> Le gouvernement représentatif n'est pas la démocratie -- >>>> http://www.le-message.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers >>> >>> >>> It's not blocking 2.8.9 -- yet! -- but please get to it as soon as you >>> can, and let us know when you've merged a fix to 'next'. >>> >>> Thanks, >>> David >> >> >> >> A better alternative (I think) would be to run the same kind of code >> you are running now, but to do it at the correct time. i.e. -- execute >> the code that is currently running at cmake configure time via a >> script that gets invoked when the test is run. > > This is true but it makes the CPack testing not so obvious. > Since the current code was used to create tests so we get a > chicken and eggs problem. > > currently after (initial) configuration I can do: > ctest -R RPM -N > > and get the list of tests? > What filtering capability would I get if the test itself is generating > subtest? > > The issue here is that CMake is assumed to be there when CMake itself > is built ( because CMake can/must be boostrapped) whereas CPack may > not be there when it is built. > > A possible solution would be to separate the definition of all the > CPack related tests > in order to define them when we know that CPack has been built. > >> Then you *can* reliably >> use the built cpack to see what generators it says it supports, and >> use those as the list of generators to test. > > In order to get this fix fast enough I did not implement this solution now, > I'll think more about. > The current fix (in next): > Merge topic 'DoNotInvokeCPackAtCMakeTime-forCMakeTests' into next > > 848f220 Do not run cpack at CMake time it is not available. > > just checks for rpmbuild and dpkg availability. > > -- > Erk > Le gouvernement représentatif n'est pas la démocratie -- > http://www.le-message.org
On our dashmacmini3 dashboards, we're getting: DPKG_EXECUTABLE='/sw/bin/dpkg' It's found by find_program at CMake configure time, but cpack does not find this program (it's not in the PATH) at testing time. What should we do about this? I could just set DPKG_EXECUTABLE=OFF to circumvent the test on these 3 dashboards for now... But I'd like a real fix for it. Seems like cpack should find it if CMake's find_program can find it. Thx, David -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
