On Tuesday 21 June 2011, Brad King wrote:
On 06/20/2011 06:23 PM, Alexander Neundorf wrote:
I moved part of the documentation now to the variable section.
Better ?
Nice, thanks.
While looking at it, I'm not sure anymore the name
DISABLE_FIND_PACKAGE_Name is good.
Should it
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12295
==
Reported By:Ben Medina
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12296
==
Reported By:spa
Assigned To:
header files in directory change should cause rebuild?
Doesn't cmake parse the c files for includes and auto build header dependancies?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
On 06/21/2011 10:51 AM, J Decker wrote:
header files in directory change should cause rebuild?
Doesn't cmake parse the c files for includes and auto build header
dependancies?
Sorry, can you rephrase your question? Preferably using complete
sentences, so people are actually are able to
Okay I have many many projects and targets using cmake to build them.
I target openwatcom stock install, mingw stock install, and vs2010
stock install + cmake + my sources
Often when I make a change to sack/includes/*.h everything rebuilds
appropriately.
If I change a header in a library that's
Hi James,
Thanks you for feedback. See my comments:
I dismissed the idea of using the cmake dependency scanner, because it was a
makefile only solution. I wasn't interested in maintaining multiple code
paths. It's much better for testing to have it work basically the same way
everywhere.
On Tue, Jun 21, 2011 at 5:11 AM, J Decker d3c...@gmail.com wrote:
Okay I have many many projects and targets using cmake to build them.
I target openwatcom stock install, mingw stock install, and vs2010
stock install + cmake + my sources
Often when I make a change to sack/includes/*.h
On 06/17/2011 04:59 PM, Eric Noulard wrote:
OK I have the same behavior on my box using your example.
I did open a bug report:
http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
http://www.cmake.org/Bug/view.php?id=12284#c26931
CPack recursively collects all
Hi,
Thanks for the response. I've got a few followups.
Clinton Stimpson wrote:
The part that is not clear to me is this:
This
means when a project B then uses project A, these imported targets must
be created again, otherwise e.g. Qt4__QtCore will be interpreted as
name of a library
David Cole ha scritto:
On Mon, Jun 20, 2011 at 6:11 AM, Kalev
Lember ka...@smartlink.ee
wrote:
Could
you please pull in the following commit from -next into next rc?
It fixes a regression with locating swig executable in FindSWIG module.
commit
On Tue, Jun 21, 2011 at 9:05 AM, Andrea Galeazzi galea...@korg.it wrote:
**
David Cole ha scritto:
On Mon, Jun 20, 2011 at 6:11 AM, Kalev Lember ka...@smartlink.ee wrote:
Could you please pull in the following commit from -next into next rc?
It fixes a regression with locating swig
Dear CMake list,
when building external libraries such as ITK, VTK, etc. from source,
XCode 4.0.1 is not able to import the BuildType parameter set in Cmake
2.8-4. When setting CMAKE_BUILD_TYPE = Release, still XCode uses Debug
as build type. Has someone else observed this behavior?
On 06/21/2011 03:31 PM, Ignaz Reicht wrote:
Dear CMake list,
when building external libraries such as ITK, VTK, etc. from source,
XCode 4.0.1 is not able to import the BuildType parameter set in Cmake
2.8-4. When setting CMAKE_BUILD_TYPE = Release, still XCode uses Debug
as build type. Has
On 6/21/11 6:28 AM, Brad King wrote:
On 06/17/2011 04:59 PM, Eric Noulard wrote:
OK I have the same behavior on my box using your example.
I did open a bug report:
http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
I updated the bug with this patch and some of the details from below.
Aaron C. Meadows
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Meadows, Aaron C.
Sent: Monday, June 20, 2011 5:17 PM
To: cmake@cmake.org
Subject: [CMake] Bug #12189
(link:
thank you
Am 21.06.2011 um 16:07 schrieb Michael Wild:
On 06/21/2011 03:31 PM, Ignaz Reicht wrote:
Dear CMake list,
when building external libraries such as ITK, VTK, etc. from source,
XCode 4.0.1 is not able to import the BuildType parameter set in
Cmake
2.8-4. When setting
2011/6/21 John R. Cary c...@txcorp.com:
On 6/21/11 6:28 AM, Brad King wrote:
On 06/17/2011 04:59 PM, Eric Noulard wrote:
OK I have the same behavior on my box using your example.
I did open a bug report:
http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
On Tuesday, June 21, 2011 06:59:25 am Stephen Kelly wrote:
Hi,
Thanks for the response. I've got a few followups.
Clinton Stimpson wrote:
The part that is not clear to me is this:
This
means when a project B then uses project A, these imported targets
must be created again,
Good day all,
I am using ADD_TEST like this:
ADD_TEST(
nameOfMyTest
${CMAKE_CTEST_COMMAND}
--build-and-test ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR}
--build-generator ${CMAKE_GENERATOR}
--build-makeprogram ${CMAKE_BUILD_TOOL}
--build-nocmake
--build-noclean
On Tue, Jun 21, 2011 at 12:09 PM, Hugo Heden he...@foi.se wrote:
**
Good day all,
I am using ADD_TEST like this:
ADD_TEST(
nameOfMyTest
${CMAKE_CTEST_COMMAND}
--build-and-test ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR}
--build-generator ${CMAKE_GENERATOR}
Should not the cmake help web page (
http://www.cmake.org/cmake/help/help.html) contain a link to the
documentation page?
--
Cheers,
Kishore
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
Good suggestion.
In the meantime, please find the link to the documentation page on the cmake
resources web page:
http://www.cmake.org/cmake/resources/resources.html
Thanks,
David
On Tue, Jun 21, 2011 at 1:55 PM, Kishore Jonnalagadda
kitts.mailingli...@gmail.com wrote:
Should not the
On Jun 21, 2011 11:29 PM, David Cole david.c...@kitware.com wrote:
Good suggestion.
In the meantime, please find the link to the documentation page on the
cmake resources web page:
http://www.cmake.org/cmake/resources/resources.html
It's not the page I expect... I expected a link to the
Since I got no feedback, I assume it's a bug. I've filed it here:
0012295: LINK_FLAGS_RELEASE has no effect on static libraries for MSVC
generators
http://www.cmake.org/Bug/view.php?id=12295
On Mon, Jun 13, 2011 at 11:50 AM, Ben Medina ben.med...@gmail.com wrote:
Hello all,
I'm using CMake
On Tue, Jun 21, 2011 at 4:18 AM, David Cole david.c...@kitware.com wrote:
On Tue, Jun 21, 2011 at 5:11 AM, J Decker d3c...@gmail.com wrote:
Okay I have many many projects and targets using cmake to build them.
I target openwatcom stock install, mingw stock install, and vs2010
stock install +
On 06/22/2011 01:25 AM, J Decker wrote:
[...]
just an observation ; gcc can generate dependancies as it is
compiling, if these dependancies are included in make with
-include file.depends.d
then it doesn't fail during first build when there is none; anyhow
that removes the nessecity to
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 9a296ab5bc6c7031acb55031ee34376785233838 (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 e355a1263163b201bbeeafe9c974b8f914075cf2 (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, release has been updated
via e8e1048c5ff7b625af32cee6a3072e8d979d2033 (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 0d5fcf9e761131432667aa93d1ba42ee3f185585 (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, master has been updated
via d0d5540dc6593ea635050738be9073e40a1eabde (commit)
from
32 matches
Mail list logo
