[cmake-developers] trouble with running cpack --help during cmake step

[David Cole]

On Thu, Jun 28, 2012 at 8:04 AM, Eric Noulard <eric.noulard at gmail.com> wrote:
> 2012/6/27 David Cole <david.cole at kitware.com>:
>> On Tue, Jun 26, 2012 at 6:31 PM, David Cole <david.cole at kitware.com> wrote:
>>> On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard <eric.noulard at gmail.com> wrote:
>>>> 2012/6/26 Bill Hoffman <bill.hoffman at kitware.com>:
>>>>> 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