Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Variable expansion missing global reference #83

Closed
evmar opened this issue Aug 30, 2023 · 0 comments
Closed

Variable expansion missing global reference #83

evmar opened this issue Aug 30, 2023 · 0 comments

Comments

@evmar
Copy link
Owner

evmar commented Aug 30, 2023

#39 (comment)

Distilled it to:

var = 123
rule custom
  command = $cmd $var
build out: custom
  cmd = echo $var hello

This runs echo hello 123 when it should run echo 123 hello 123
@evmar evmar mentioned this issue Aug 30, 2023
Open
evmar added a commit that referenced this issue Aug 30, 2023
@evmar
add currently-failing test case for issue #83
00dcdbe
@evmar evmar closed this as completed in 3a39030 Aug 30, 2023
Colecf added a commit to Colecf/n2 that referenced this issue Dec 29, 2023
@Colecf
Evaluate build paths in the context of the build's bindings
5a95522 
This fixes an incompatibility with ninja.

I've also refactored Env to make it clearer and remove the TODO(evmar#83),
but I actually think we could do signifigant further cleanup. Only
rules should require EvalStrings, global variables and build bindings
can be evaluated as soon as they're read, although maybe that would
change with subninjas. Also, rules currently parse their variables as
EvalString<String>, but I think that could be changed to
EvalString<&'text str> if we hold onto the byte buffers of all the
included files until the parsing is done.

Fixes evmar#91, and evmar#39.
Colecf added a commit to Colecf/n2 that referenced this issue Dec 29, 2023
@Colecf
Evaluate build paths in the context of the build's bindings
eec13b0 
This fixes an incompatibility with ninja.

I've also refactored Env to make it clearer and remove the TODO(evmar#83),
but I actually think we could do signifigant further cleanup. Only
rules should require EvalStrings, global variables and build bindings
can be evaluated as soon as they're read, although maybe that would
change with subninjas. Also, rules currently parse their variables as
EvalString<String>, but I think that could be changed to
EvalString<&'text str> if we hold onto the byte buffers of all the
included files until the parsing is done.

Fixes evmar#91 and evmar#39.
Colecf added a commit to Colecf/n2 that referenced this issue Dec 29, 2023
@Colecf
Evaluate build paths in the context of the build's bindings
977324d 
This fixes an incompatibility with ninja.

I've also refactored Env to make it clearer and remove the TODO(evmar#83),
but I actually think we could do signifigant further cleanup. Only
rules should require EvalStrings, global variables and build bindings
can be evaluated as soon as they're read, although maybe that would
change with subninjas. Also, rules currently parse their variables as
EvalString<String>, but I think that could be changed to
EvalString<&'text str> if we hold onto the byte buffers of all the
included files until the parsing is done.

Fixes evmar#91 and evmar#39.
Colecf added a commit to Colecf/n2 that referenced this issue Dec 29, 2023
@Colecf
Evaluate build paths in the context of the build's bindings
7b64b7d 
This fixes an incompatibility with ninja.

I've also refactored Env to make it clearer and remove the TODO(evmar#83),
but I actually think we could do signifigant further cleanup. Only
rules should require EvalStrings, global variables and build bindings
can be evaluated as soon as they're read, although maybe that would
change with subninjas. Also, rules currently parse their variables as
EvalString<String>, but I think that could be changed to
EvalString<&'text str> if we hold onto the byte buffers of all the
included files until the parsing is done.

Fixes evmar#91 and evmar#39.
Colecf added a commit to Colecf/n2 that referenced this issue Dec 29, 2023
@Colecf
Evaluate build paths in the context of the build's bindings
3f797e6 
This fixes an incompatibility with ninja.

I've also refactored Env to make it clearer and remove the TODO(evmar#83),
but I actually think we could do signifigant further cleanup. Only
rules should require EvalStrings, global variables and build bindings
can be evaluated as soon as they're read, although maybe that would
change with subninjas. Also, rules currently parse their variables as
EvalString<String>, but I think that could be changed to
EvalString<&'text str> if we hold onto the byte buffers of all the
included files until the parsing is done.

Fixes evmar#91 and evmar#39.
Colecf added a commit to Colecf/n2 that referenced this issue Dec 29, 2023
@Colecf
Evaluate build paths in the context of the build's bindings
de42648 
This fixes an incompatibility with ninja.

I've also refactored Env to make it clearer and remove the TODO(evmar#83),
but I actually think we could do signifigant further cleanup. Only
rules should require EvalStrings, global variables and build bindings
can be evaluated as soon as they're read, although maybe that would
change with subninjas. Also, rules currently parse their variables as
EvalString<String>, but I think that could be changed to
EvalString<&'text str> if we hold onto the byte buffers of all the
included files until the parsing is done.

Fixes evmar#91 and evmar#39.
@Colecf Colecf mentioned this issue Dec 29, 2023
Merged
Colecf added a commit to Colecf/n2 that referenced this issue Dec 31, 2023
@Colecf
Evaluate build paths in the context of the build's bindings
9dffdcb 
This fixes an incompatibility with ninja.

I've also refactored Env to make it clearer and remove the TODO(evmar#83),
but I actually think we could do signifigant further cleanup. Only
rules should require EvalStrings, global variables and build bindings
can be evaluated as soon as they're read, although maybe that would
change with subninjas. Also, rules currently parse their variables as
EvalString<String>, but I think that could be changed to
EvalString<&'text str> if we hold onto the byte buffers of all the
included files until the parsing is done.

Fixes evmar#91 and evmar#39.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@evmar