On Fri, May 23, 2014 at 3:11 PM, Brad King wrote:
>
> That is what the above variables were meant to be. They just
> happen to be implemented by replacing during variable evaluation
> instead of by the lexer. Having the lexer do actual replacements
> would be a change to the language beyond the
On 05/23/2014 03:39 AM, Nicolas Desprès wrote:
>> One remaining challenge is CMAKE_CURRENT_LIST_FILE and
>> CMAKE_CURRENT_LIST_LINE. Since the "current file" is not
[snip]
> I think we should not touch those variables because they have
> dynamic behavior and if they are used in the generated code
On Thu, May 22, 2014 at 3:16 PM, Brad King wrote:
>
> One remaining challenge is CMAKE_CURRENT_LIST_FILE and
> CMAKE_CURRENT_LIST_LINE. Since the "current file" is not
> handled by the lexer these may not be consistent unless some
> kind of refactoring is done in the language implementation.
> Ho
On Thursday, May 22, 2014 09:16:17 Brad King wrote:
> On 05/21/2014 04:05 PM, Nicolas Desprès wrote:
> > at the time the AST node is created the file location is frozen.
> > Locations are controlled by the lexer so do comments.
>
> Correct. This has to be done by the lexer. We already have
> doc
On 05/21/2014 04:05 PM, Nicolas Desprès wrote:
> at the time the AST node is created the file location is frozen.
> Locations are controlled by the lexer so do comments.
Correct. This has to be done by the lexer. We already have
documentation blocks that are "indistinguishable from comments":
On Wed, May 21, 2014 at 9:31 PM, Matthew Woehlke <
mw_tr...@users.sourceforge.net> wrote:
> On 2014-05-21 15:24, Nicolas Desprès wrote:
> > On Wed, May 21, 2014 at 8:06 PM, Matthew Woehlke wrote:
> >> On 2014-05-15 08:36, Ben Boeckel wrote:
> >>> This will also likely need a policy since there's n
On 2014-05-21 15:24, Nicolas Desprès wrote:
> On Wed, May 21, 2014 at 8:06 PM, Matthew Woehlke wrote:
>> On 2014-05-15 08:36, Ben Boeckel wrote:
>>> This will also likely need a policy since there's no guarantee that
>>> #line "directives" don't exist in already existing code as comments.
>>
>> May
On Wed, May 21, 2014 at 8:06 PM, Matthew Woehlke <
mw_tr...@users.sourceforge.net> wrote:
> On 2014-05-15 08:36, Ben Boeckel wrote:
> > 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-proce
On 2014-05-15 08:36, Ben Boeckel wrote:
> 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
On Thu, May 15, 2014 at 4:05 PM, Brad King 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 mentioned #lin
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 thoug
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
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. Help
On Thu, May 15, 2014 at 2:54 PM, Brad King 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 forget tests :) .
>
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 p
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
> u
On Thu, May 15, 2014 at 10:15 AM, Eric Noulard wrote:
> 2014-05-15 10:08 GMT+02:00 Nicolas Desprès :
> > 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 approache
2014-05-15 10:08 GMT+02:00 Nicolas Desprès :
> 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.
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
witho
19 matches
Mail list logo
