Re: [cmake-developers] trouble with running cpack --help during cmake step
On Sun, Jul 15, 2012 at 6:17 PM, Eric Noulard wrote: > 2012/7/12 David Cole : > >> I pushed this to 'next' the other day, but the test failures on dashmacmini3 >> remain, so the latest commit is not having its intended effect. >> >> Back to Bill's original assertion: >> "I am not sure how this works on a fresh build tree either as cpack won't >> even exist." > > Yes Bill is right, I did check that but may be not thoroughly enough. > CPack/CMake etc... is installed at several place on my dev system > next time I'll check that no install cpack command may be used > during CMake fresh build. > >> It must work on fresh build trees, because all of our Nightly dashboards >> work from fresh build trees. Since those work (even before this recent >> branch), there must be something else going on here. > > May be. > The problem I see here "generic" CMake is bootstrapped > CPack is not, if it was we > could assume that CPack *is* available when CMake is. > > >> We're not going to merge this into 'master' until we get it right... I'll >> take a look at this tomorrow if you don't have time to spend on it right >> now, Eric. > > Sorry for the delayed answer. > This is a good decision as usual. > > I have not enough spare time right now and probably not much before July > 20th... > I'm organizing a conference and this eats most of my time. > > -- > Erk > Le gouvernement représentatif n'est pas la démocratie -- > http://www.le-message.org I just pushed one more commit on top of the existing stage branch to address the test failures on dashmacmini3. We were missing the "/bin" suffix on all the search paths in the C++ code. Those are directories, whereas in the .cmake modules you modeled it after, we just set prefix values and look automatically in the bin subdir. Should be fixed tomorrow. D -- 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
Re: [cmake-developers] trouble with running cpack --help during cmake step
2012/7/12 David Cole : > I pushed this to 'next' the other day, but the test failures on dashmacmini3 > remain, so the latest commit is not having its intended effect. > > Back to Bill's original assertion: > "I am not sure how this works on a fresh build tree either as cpack won't > even exist." Yes Bill is right, I did check that but may be not thoroughly enough. CPack/CMake etc... is installed at several place on my dev system next time I'll check that no install cpack command may be used during CMake fresh build. > It must work on fresh build trees, because all of our Nightly dashboards > work from fresh build trees. Since those work (even before this recent > branch), there must be something else going on here. May be. The problem I see here "generic" CMake is bootstrapped CPack is not, if it was we could assume that CPack *is* available when CMake is. > We're not going to merge this into 'master' until we get it right... I'll > take a look at this tomorrow if you don't have time to spend on it right > now, Eric. Sorry for the delayed answer. This is a good decision as usual. I have not enough spare time right now and probably not much before July 20th... I'm organizing a conference and this eats most of my time. -- 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
Re: [cmake-developers] trouble with running cpack --help during cmake step
On Thu, Jul 5, 2012 at 5:27 AM, Eric Noulard wrote: > 2012/7/2 Eric Noulard : > > 2012/7/2 David Cole : > >> > >> > >> Probably because of this: > >> > >> LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH > >> /sw# Fink > >> /opt/local # MacPorts > >> ) > >> > >> from Darwin.cmake... > > > > OK could you try my proposal I just pushed on stage: > > > > To g...@cmake.org:stage/cmake.git > >848f220..a8c659c HEAD -> DoNotInvokeCPackAtCMakeTime-forCMakeTests > > > > And of course you were right for the "get the list at test time" > > because at least > > the "non-finding" would have been consistent. > > > > I'll do that but probably not for 2.8.9. > > David, > Bill, > > Would you like me to push that to next or would you have a look first? > It would definitely be better to have the **very same** way of checking > for tools (rpmbuild and dpkg) in Tests and/or cpack main > but like I said I won't have time to implement proper logic in CMake > Tests right now. I pushed this to 'next' the other day, but the test failures on dashmacmini3 remain, so the latest commit is not having its intended effect. Back to Bill's original assertion: "I am not sure how this works on a fresh build tree either as cpack won't even exist." It must work on fresh build trees, because all of our Nightly dashboards work from fresh build trees. Since those work (even before this recent branch), there must be something else going on here. We're not going to merge this into 'master' until we get it right... I'll take a look at this tomorrow if you don't have time to spend on it right now, Eric. Thanks, 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
Re: [cmake-developers] trouble with running cpack --help during cmake step
2012/7/2 Eric Noulard : > 2012/7/2 David Cole : >> >> >> Probably because of this: >> >> LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH >> /sw# Fink >> /opt/local # MacPorts >> ) >> >> from Darwin.cmake... > > OK could you try my proposal I just pushed on stage: > > To g...@cmake.org:stage/cmake.git >848f220..a8c659c HEAD -> DoNotInvokeCPackAtCMakeTime-forCMakeTests > > And of course you were right for the "get the list at test time" > because at least > the "non-finding" would have been consistent. > > I'll do that but probably not for 2.8.9. David, Bill, Would you like me to push that to next or would you have a look first? It would definitely be better to have the **very same** way of checking for tools (rpmbuild and dpkg) in Tests and/or cpack main but like I said I won't have time to implement proper logic in CMake Tests right now. -- 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
Re: [cmake-developers] trouble with running cpack --help during cmake step
2012/7/2 David Cole :
> On Mon, Jul 2, 2012 at 11:58 AM, Eric Noulard wrote:
>> 2012/7/2 David Cole :
>>>
>>> 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.
>>
>> Yes I [apparently wrongly] supposed
>>
>> that
>> cmSystemTools::FindProgram("dpkg")
>>
>> would find 'dpkg' iff:
>> find_program(DPKG_EXECUTABLE NAMES dpkg)
>> did find it...
>>
>> Why is the result of this two commands differents?
>> Are there some env var that makes the behavior different?
>> Or may be the configure environement is different from
>> the test environment...
>>
>>
>> --
>> Erk
>> Le gouvernement représentatif n'est pas la démocratie --
>> http://www.le-message.org
>
>
> Probably because of this:
>
> LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH
> /sw# Fink
> /opt/local # MacPorts
> )
>
> from Darwin.cmake...
OK could you try my proposal I just pushed on stage:
To g...@cmake.org:stage/cmake.git
848f220..a8c659c HEAD -> DoNotInvokeCPackAtCMakeTime-forCMakeTests
And of course you were right for the "get the list at test time"
because at least
the "non-finding" would have been consistent.
I'll do that but probably not for 2.8.9.
--
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
Re: [cmake-developers] trouble with running cpack --help during cmake step
On Mon, Jul 2, 2012 at 11:58 AM, Eric Noulard wrote:
> 2012/7/2 David Cole :
>>
>> 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.
>
> Yes I [apparently wrongly] supposed
>
> that
> cmSystemTools::FindProgram("dpkg")
>
> would find 'dpkg' iff:
> find_program(DPKG_EXECUTABLE NAMES dpkg)
> did find it...
>
> Why is the result of this two commands differents?
> Are there some env var that makes the behavior different?
> Or may be the configure environement is different from
> the test environment...
>
>
> --
> Erk
> Le gouvernement représentatif n'est pas la démocratie --
> http://www.le-message.org
Probably because of this:
LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH
/sw# Fink
/opt/local # MacPorts
)
from Darwin.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] trouble with running cpack --help during cmake step
2012/7/2 David Cole :
>
> 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.
Yes I [apparently wrongly] supposed
that
cmSystemTools::FindProgram("dpkg")
would find 'dpkg' iff:
find_program(DPKG_EXECUTABLE NAMES dpkg)
did find it...
Why is the result of this two commands differents?
Are there some env var that makes the behavior different?
Or may be the configure environement is different from
the test environment...
--
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
Re: [cmake-developers] trouble with running cpack --help during cmake step
On Thu, Jun 28, 2012 at 8:04 AM, Eric Noulard wrote:
> 2012/6/27 David Cole :
>> On Tue, Jun 26, 2012 at 6:31 PM, David Cole wrote:
>>> On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard
>>> wrote:
2012/6/26 Bill Hoffman :
> 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,
Dav
Re: [cmake-developers] trouble with running cpack --help during cmake step
2012/6/27 David Cole :
> On Tue, Jun 26, 2012 at 6:31 PM, David Cole wrote:
>> On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard wrote:
>>> 2012/6/26 Bill Hoffman :
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
Re: [cmake-developers] trouble with running cpack --help during cmake step
On Tue, Jun 26, 2012 at 6:31 PM, David Cole wrote:
> On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard wrote:
>> 2012/6/26 Bill Hoffman :
>>> 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. 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.
Thanks (again),
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
Re: [cmake-developers] trouble with running cpack --help during cmake step
On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard wrote:
> 2012/6/26 Bill Hoffman :
>> 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
--
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
Re: [cmake-developers] trouble with running cpack --help during cmake step
2012/6/26 Bill Hoffman :
> 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
[cmake-developers] trouble with running cpack --help during cmake step
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.
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
--
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
