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
22 matches
Mail list logo
