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
Hi,
On Ubuntu, compiling python 2.5.6 following the instruction listed here [1]
works.
[1]
http://www.vtk.org/Wiki/BuildingPythonWithCMake#Building_Python_for_Linux_or_Windows
Somebody with mingw will have to check what's wrong.
Step by step:
wget
To actually run the coverage testing, you need to have tests added with
add_test in your CMakeLists file, then you need to run a ctest -S script that
calls ctest_coverage, or use one of the predefined coverage dashboard targets.
(Use 'make help | grep Coverage' to see those.)
On Jan 2, 2012,
On Tue, Jan 3, 2012 at 9:52 AM, David Cole david.c...@kitware.com wrote:
To actually run the coverage testing, you need to have tests added with
add_test in your CMakeLists file, then you need to run a ctest -S script
that calls ctest_coverage, or use one of the predefined coverage dashboard
The way I have always approached problems like this is to check out
what existing scripts are doing that are already successfully
submitting coverage results.
This one is on the VTK dashboard:
http://cdash.org/CDash/viewNotes.php?buildid=1880030
This one on CMake:
The Cite extension is now installed on the CMake wiki. See this page
to see what mediawiki extensions are available:
http://www.cmake.org/Wiki/Special:Version
HTH,
David
On Mon, Jan 2, 2012 at 12:03 PM, Johannes Zarl johannes.z...@jku.at wrote:
Hi David,
I guess I'll have time this week
hi, thnx for helping.
interesting to see you use the 251 cmake unaltered for 256 and it works. I
guess the path building problem is a mingw thing indeed. why would it
create another CMakeFiles in CMakeTmp? Where can I find the script that
prescribes this?
I just added a screenie of explorer
On Thursday 29 December 2011, Eric Noulard wrote:
2011/12/29 Ryan Lewis m...@ryanlewis.net:
Hi,
I really like CMake's find_package() utility for finding dependencies,
but for some projects I have a
separate local copy of the installed libraries, and I want to point
find_package at a
2012/1/3 Alexander Neundorf a.neundorf-w...@gmx.net:
you basically want:
set(CMAKE_FIND_ROOT_PATH /you/local/install/dir)
before calling find_package(...)
No, please don't.
CMAKE_FIND_ROOT_PATH is intended for cross-compiling, to tell cmake where the
root of the target file system is
Might be nice to decide about this one:
http://public.kitware.com/Bug/view.php?id=4756
Sean
--
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:
I'm back to this. I never got (or never understood!) an answer to this part of
the thread, which is where the breakage occurred:
--
If I comment out line 29 in CMakeDetermineCompilerId.cmake, it works with my
old toolchain file, but fails later with the new one, because it appears to
http://public.kitware.com/Bug/view.php?id=8438
http://public.kitware.com/Bug/view.php?id=11258
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:
I have a large static library comprised of C, C++, Fortran, and Ada source
files.
I have a number of C, C++, Fortran, and Ada executables linking against this
library.
When CMake generates the link statements in link.txt, the implicit libraries
selected to be linked against from the
On Tue, Jan 3, 2012 at 2:30 PM, Schuchard, Matthew
matthew.schuch...@gtri.gatech.edu wrote:
I have a large static library comprised of C, C++, Fortran, and Ada source
files.
I have a number of C, C++, Fortran, and Ada executables linking against this
library.
When CMake generates the link
On Monday 02 January 2012, David Cole wrote:
Hi all,
Replies requested. Short replies only. Read on. Just a short reply
with bug numbers or links to the bugs is all we need here. Please move
specific discussions into the bugs themselves or start a new thread to
talk about it... Replies on
http://public.kitware.com/Bug/view.php?id=12652
--
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
Hi,
I am building and installing full 64bit applications and libraries.
When I package it up as an installer via NSIS, it installs to
C:\Program Files (x86)\
What CPACK_ variables do I need to inform cpack that it should be
installed in C:\Program Files\
Regards
--
Nicholas
On Tue, Jan 3, 2012 at 8:05 PM, Nicholas Yue yue.nicho...@gmail.com wrote:
Hi,
I am building and installing full 64bit applications and libraries.
When I package it up as an installer via NSIS, it installs to C:\Program
Files (x86)\
What CPACK_ variables do I need to inform
On Tue, Jan 3, 2012 at 8:05 PM, Nicholas Yue yue.nicho...@gmail.com wrote:
Hi,
I am building and installing full 64bit applications and libraries.
When I package it up as an installer via NSIS, it installs to C:\Program
Files (x86)\
What CPACK_ variables do I need to inform cpack
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The annotated tag, v2.8.7 has been created
at 2e974af269a523a8ffa1d5251061c7a5a81dadcc (tag)
tagging
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4f132efd7d7203a3b725af95a9d2c394386ae611 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 835d6f3e2d8fea1d1c7f4179f362235d1e5d4d8d (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0da55e05a9e6aabcf806f2fb0c79465c5ffbf5e7 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 135932415b3de7975a6fc90606b04b9e0471523d (commit)
via
44 matches
Mail list logo
