Too bad it did not make it to RC3...
This is a really nice feature.
Neither RC4 nor RC5.
Any chance to get it pulled?
Cheers,
Manu
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to
Short form: I tell FindOpenSSL where to look by setting OPENSSL_ROOT_DIR to
point to my shiny new OpenSSL install; it ignores me and finds ancient,
vulnerable OpenSSL libraries to use instead.)
Some info about my build environment:
* pristine install of cmake 2.8.12.2-win32-x86
* Open VS2012 x64
Somehow I have corrupted the Visual studio macro, and its no longer effective
when cmake is run.
I have tried uninstalling and re-installing cmake, and it doesn't resetup the
macro. Is there a registry setting somewhere? Or a addin I need to manually
uninstall?
VS 2008 btw..
Scott
--
Hello everyone, i need your help because cmake is show me this message:
***
CMake Error in CDAUtils/src/CMakeLists.txt:
Target escmga-siscp-utils INTERFACE_INCLUDE_DIRECTORIES property contains
path:
There is currently no way to exclude a specific install from a full
installation. Users often attempt to do so by adding EXCLUDE_FROM_ALL as per
add_executable()/add_library(). This patch adds support for EXCLUDE_FROM_ALL to
the install() command so that users can exclude it from a full
Hello,
I would like CMake to not set the following property in the project at all:
ARCHS = $(ARCHS_STANDARD)
That is, I would like this property to not even show up in the
*pbxproj*file (which can be found inside the generated
*xcodeproj* bundle. In fact, I would like it to be removed by CMake.
Hi,
I am planning to develop a python generator of CMakeLists.txt file for
easier integration in an already existing tool. This approach is different
from the others approaches consisting in binding the CMake language in a
foreign languages. Lua, Javascript and Python have already been tried
2014-05-15 10:08 GMT+02:00 Nicolas Desprès nicolas.desp...@gmail.com:
Hi,
I am planning to develop a python generator of CMakeLists.txt file for
easier integration in an already existing tool. This approach is different
from the others approaches consisting in binding the CMake language in a
In the context of http://www.cmake.org/Bug/view.php?id=14911 I've been
thinking it would be nice if there were properties for installed files
like there are for source files.
For my purposes they would have to be exported for CPack (e.g. in
CPackConfig.cmake) similar to how test properties
On Thu, May 15, 2014 at 10:15 AM, Eric Noulard eric.noul...@gmail.comwrote:
2014-05-15 10:08 GMT+02:00 Nicolas Desprès nicolas.desp...@gmail.com:
Hi,
I am planning to develop a python generator of CMakeLists.txt file for
easier integration in an already existing tool. This approach is
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14916
==
Reported By:Nikolay Zapolnov
Assigned To:
On Thu, May 15, 2014 at 12:45:27 +0200, Nicolas Desprès wrote:
Nope. These variables are the cmake equivalent to the __LINE__ and __FILE__
C-pre-processor macro. What I need is the #line directive equivalent which
force the value of these variables so that error messages reported by cmake
uses
On 05/15/2014 08:36 AM, Ben Boeckel wrote:
If you'd like to try a patch, the relevant code is in
Source/cmExprParser*. Add a callback for #line nnn and update the
CurrentLine variable cmExprParserHelper.cxx. Don't forget tests :) .
cmExprParser is just for the math() command. The language
On 05/15/2014 04:33 AM, Nils Gladitz wrote:
In the context of http://www.cmake.org/Bug/view.php?id=14911 I've been
thinking it would be nice if there were properties for installed files
like there are for source files.
For my purposes they would have to be exported for CPack (e.g. in
On Thu, May 15, 2014 at 2:54 PM, Brad King brad.k...@kitware.com wrote:
On 05/15/2014 08:36 AM, Ben Boeckel wrote:
If you'd like to try a patch, the relevant code is in
Source/cmExprParser*. Add a callback for #line nnn and update the
CurrentLine variable cmExprParserHelper.cxx. Don't
On 05/15/2014 09:11 AM, Nicolas Desprès wrote:
Do you think such a patch would be accepted after version 3 has
been released?
I have no objection to the proposed feature to support generated
files mapping back to other sources. If the patch is sound and
has associated documentation (e.g.
On Thu, May 15, 2014 at 09:22:32 -0400, Brad King wrote:
I do not think the policy Ben mentioned will be needed. The syntax
#line 1234 /path/to/real/file
is fairly obscure and will be treated as a comment by older CMakes.
My thought was that such rogue existing comments might give really
On 05/15/2014 03:06 PM, Brad King wrote:
Here is a quick brainstorm:
Just like CTestTestfile for testing and cmake_install for installation,
perhaps we need a per-directory hierarchical cmake_package for CPack.
We could re-use source file properties. When the install() command
is installing a
On 05/15/2014 09:50 AM, Nils Gladitz wrote:
I was thinking about using destination paths as the property key in
CMakeLists.txt code consistently since this would also work for files
created by any type of installation (including CODE/SCRIPT).
Yes, that makes sense. The keys could each be
On 05/15/2014 09:39 AM, Ben Boeckel wrote:
On Thu, May 15, 2014 at 09:22:32 -0400, Brad King wrote:
I do not think the policy Ben mentioned will be needed. The syntax
#line 1234 /path/to/real/file
is fairly obscure and will be treated as a comment by older CMakes.
My thought was that
On 05/15/2014 04:02 PM, Brad King wrote:
On 05/15/2014 09:50 AM, Nils Gladitz wrote:
Yes, that makes sense. The keys could each be either a relative path
(to the install prefix) or an absolute path. We would not need any
new commands. The set_property and get_property command could learn
a
On Thu, May 15, 2014 at 4:05 PM, Brad King brad.k...@kitware.com wrote:
Since the files are generated there is no reason the syntax has to
be short. We could use:
#cmake-generated-from-line 1234 /path/to/real/file
or:
#cmake-source-line 1234 /path/to/real/file
That's true. I
On 05/15/2014 10:14 AM, Nils Gladitz wrote:
Assuming there are no use cases which would make these properties useful
at install time as well I would suggest CPACK otherwise INSTALL.
Let's go with CPACK for now. If we find a use case for INSTALL
later we can always teach CPack to understand
On 05/15/2014 04:23 PM, Brad King wrote:
On 05/15/2014 10:14 AM, Nils Gladitz wrote:
Assuming there are no use cases which would make these properties useful
at install time as well I would suggest CPACK otherwise INSTALL.
Let's go with CPACK for now. If we find a use case for INSTALL
later
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14917
==
Reported By:Andreas Boerner
Assigned To:
I have recently been reminded that the cmake -E remove command has a
limitation due to the length of command line that is acceptable to
whatever shell is being used. Is there any willingness to remove that
limitation (in which case it would be worthwhile for me to make a
formal bug report) or is
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14918
==
Reported By:Dave Dyer
Assigned To:
On Thu, May 15, 2014 at 13:23:10 -0700, Alan W. Irwin wrote:
I have recently been reminded that the cmake -E remove command has a
limitation due to the length of command line that is acceptable to
whatever shell is being used. Is there any willingness to remove that
limitation (in which case
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 5ca7b3792b74f2fbaa6369dd34acfe4a6c2d8d04 (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 68983d2833be28caecd8d34867c88a8afc8631d3 (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 1f9e5a16a8592115386d1d0ea9419c43648095db (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 032961c6ac81d82270a7b1986935111aa5e32a56 (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 5527cfa002f50a644bf6bbb6a1a7af534870df35 (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 cad5ad5449d2f9ff87997c75a760592e9e48c6b0 (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 e8f8000289ea812e8f97d58940bbec218c34e4ac (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 8b10a15f2760a6afc8f64200147cae8c9963dea1 (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 a17dacbf128ac1a584117463cc7b889f4f6e161e (commit)
via
20140515)
+set(CMake_VERSION_PATCH 20140516)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
38 matches
Mail list logo
