2012/6/27 David Cole <david.c...@kitware.com>:
> On Tue, Jun 26, 2012 at 6:31 PM, David Cole <david.c...@kitware.com> wrote:
>> On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard <eric.noul...@gmail.com> wrote:
>>> 2012/6/26 Bill Hoffman <bill.hoff...@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
--
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
