-
Notifications
You must be signed in to change notification settings - Fork 25
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.
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
Variable references in build inputs don't take into account the build's bindings #91
Comments
This is #39 and it is dumb that I didn't make it work, but I was greedy. The reason for my greed is that n2 currently expands everything right while it parses, so when it sees Now that I look at your example, I wonder if I could do some trick around assuming things will go the fast way and then if I see a variable reference later going back and re-expanding. Or if I should just buffer everything anyway. It would probably help for me to actually profile before I micro-optimize in this manner. |
Relevant expansion inline code, I think maybe that ought to consult more scopes than it currently does too... |
Oh, feel free to close as a duplicate then. Interestingly, this issue also causes parse errors:
Produces:
I actually think this will need to be properly fixed for the android build. Not all of these search results, but many of them, suffer from this issue. |
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.
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.
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.
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.
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.
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.
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.
This fixes an incompatibility with ninja. I've also moved a bunch of variable evaluations out of the parser and into the loader, in preparation for parsing the build file in multiple threads, and then only doing the evaluations after all the chunks of the file have been parsed. Fixes evmar#91 and evmar#39.
This fixes an incompatibility with ninja. I've also moved a bunch of variable evaluations out of the parser and into the loader, in preparation for parsing the build file in multiple threads, and then only doing the evaluations after all the chunks of the file have been parsed. Fixes evmar#91 and evmar#39.
This fixes an incompatibility with ninja. I've also moved a bunch of variable evaluations out of the parser and into the loader, in preparation for parsing the build file in multiple threads, and then only doing the evaluations after all the chunks of the file have been parsed. Fixes evmar#91 and evmar#39.
(Sorry for not responding yet -- your other patches were obvious merges, but this one is more subtle so I want to give it proper attention and I have some life stuff going on the next week or so.) |
This fixes an incompatibility with ninja. I've also moved a bunch of variable evaluations out of the parser and into the loader, in preparation for parsing the build file in multiple threads, and then only doing the evaluations after all the chunks of the file have been parsed. Fixes evmar#91 and evmar#39.
Thanks for the update, I'll hold off on new PRs for now then. |
This fixes an incompatibility with ninja. I've also moved a bunch of variable evaluations out of the parser and into the loader, in preparation for parsing the build file in multiple threads, and then only doing the evaluations after all the chunks of the file have been parsed. Fixes evmar#91 and evmar#39.
This build file works in ninja, but not n2. Android has this case. I've only found one occurance that was trivial to remove so far, but I haven't gotten a full build working yet. If possible, maybe it's better not to fix it if it allows faster parsing.
The text was updated successfully, but these errors were encountered: