On 1/2/2012 7:25 PM, Eric Noulard wrote:
Just pushed it forward on stage:
see:
http://public.kitware.com/Bug/view.php?id=10067
It looks like it cannot be merged [automatically] to next anymore.
It is possible that the conflicting change is already in master.
That is a justification to merge
On 1/2/2012 5:24 PM, Rolf Eike Beer wrote:
It looks like gcc simply optimizes out any reference to the tested symbol.
Given the fact that we don't really ever use that symbol anywhere it is even
correct to do so. Just that this is not what we want.
Yuck. Clearly a less-optimizable approach is
On 1/2/2012 7:43 PM, Eric Noulard wrote:
I try to push forward the feature request:
http://public.kitware.com/Bug/view.php?id=10067
[snip]
Anybody have some time to try this?
I'd like to have some feedback before going on.
The branch is stage/ImproveCPackDoc.
Please factor out the
2012/1/3 Brad King brad.k...@kitware.com:
On 1/2/2012 7:43 PM, Eric Noulard wrote:
I try to push forward the feature request:
http://public.kitware.com/Bug/view.php?id=10067
[snip]
Anybody have some time to try this?
I'd like to have some feedback before going on.
The branch is
2012/1/3 Eric Noulard eric.noul...@gmail.com:
2012/1/3 Brad King brad.k...@kitware.com:
On 1/2/2012 7:43 PM, Eric Noulard wrote:
I try to push forward the feature request:
http://public.kitware.com/Bug/view.php?id=10067
[snip]
Anybody have some time to try this?
I'd like to have some
On 1/3/2012 11:03 AM, Eric Noulard wrote:
stage/ImproveCPackDoc-part1
contains changes that do not add features but document existing ones.
This one looks good. Please merge to next.
stage/CMake-completion-improvement
contains the completion update.
This can be merged to
2012/1/3 Brad King brad.k...@kitware.com:
On 1/3/2012 11:03 AM, Eric Noulard wrote:
stage/ImproveCPackDoc-part1
contains changes that do not add features but document existing ones.
This one looks good. Please merge to next.
It does not merge without conflict:
d2c9626 Document
On 1/3/2012 11:45 AM, Eric Noulard wrote:
this is due to the fact I did already merge it
(the beginning of the old stage/ImproveCPackDoc)
to next before 2.8.7 in the hope that it would be included in 2.8.7:
http://public.kitware.com/Bug/view.php?id=10067#c27793
It was dropped because
2012/1/3 Brad King brad.k...@kitware.com:
On 1/3/2012 11:45 AM, Eric Noulard wrote:
this is due to the fact I did already merge it
(the beginning of the old stage/ImproveCPackDoc)
to next before 2.8.7 in the hope that it would be included in 2.8.7:
2012/1/3 Eric Noulard eric.noul...@gmail.com:
I did remove old ImproveCPackDoc from stage.
I did remove old CMake-completion-improvement from stage as well
and I'll push something clean without reference to potential cpack enhancement
in a new topic.
Done as well:
Merge topic
Hi All,
I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH
which seems to be reserved for cross-compiling whereas
CMAKE_PREFIX_PATH
CMAKE_INCLUDE_PATH
CMAKE_PROGRAM_PATH
CMAKE_LIBRARY_PATH
CMAKE_IGNORE_PATH
could someone enlight me about the intended relationship between
Sorry sent too soon, finger slipped.
...
I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH
which seems to be reserved for cross-compiling whereas
CMAKE_PREFIX_PATH
CMAKE_INCLUDE_PATH
CMAKE_PROGRAM_PATH
CMAKE_LIBRARY_PATH
CMAKE_IGNORE_PATH
are meant to be used in the
On Tuesday 03 January 2012, Eric Noulard wrote:
Sorry sent too soon, finger slipped.
...
I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH
which seems to be reserved for cross-compiling whereas
CMAKE_PREFIX_PATH
CMAKE_INCLUDE_PATH
CMAKE_PROGRAM_PATH
On 1/3/2012 1:40 PM, Eric Noulard wrote:
I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH
which seems to be reserved for cross-compiling whereas
Correct.
CMAKE_PREFIX_PATH
CMAKE_INCLUDE_PATH
CMAKE_PROGRAM_PATH
CMAKE_LIBRARY_PATH
CMAKE_IGNORE_PATH
are meant to be used
On Tue, Jan 3, 2012 at 2:17 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Sorry, that was not intentional. I dropped the previous branch and created a
new one, based on current master. It has 2 commits: the first one introducing
the (hopefully) fixed CheckSymbolExists.cmake, the second one adding
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12652
==
Reported By:Sean McBride
Assigned To:
Hi Brad,
I've seen you are integrating new upstream libarchive today.
Any particular reason to pick-up 3.0.0-r3950 and
not some real version like 3.0.2 ?
I did notice that this particular version may unblock a pending CMake issue
related to symbolic link handling in zip files, see:
On 1/3/2012 4:07 PM, Eric Noulard wrote:
I've seen you are integrating new upstream libarchive today.
Any particular reason to pick-up 3.0.0-r3950 and
not some real version like 3.0.2 ?
3.0.2 wasn't out when I started that topic. I just took that day's
snapshot. The main goal/achievement of
2012/1/3 Brad King brad.k...@kitware.com:
On 1/3/2012 4:07 PM, Eric Noulard wrote:
I've seen you are integrating new upstream libarchive today.
Any particular reason to pick-up 3.0.0-r3950 and
not some real version like 3.0.2 ?
3.0.2 wasn't out when I started that topic. I just took that
On 1/3/2012 4:48 PM, Eric Noulard wrote:
3.0.2 does include the feature:
Dec 24, 2011: libarchive 3.0.2 released
Great. I started the update work less than a week before that ;)
Let's wait for you to finish your experiment with 3.0.0-r3950
then may be the first application of your work may
Mantis Bug Tracker wrote:
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=12645
==
Reported By:Michael Wild
21 matches
Mail list logo
