[bug #35468] Pattern-specific private variable addition doesn't work
Update of bug #35468 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS ___ Follow-up Comment #1: Fixed and committed. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35468 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #35410] [patch] Fix a bug with filter/filter-out functions when pattern contains only quoted percents
Follow-up Comment #3, bug #35410 (project make): I don't think the strlen() thing is worth the complexity: the average length of a word passed to filter/filter-out is pretty small. I did simplify the detection of filter vs. filter-out (and some other functions as well) though. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35410 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #35410] [patch] Fix a bug with filter/filter-out functions when pattern contains only quoted percents
Follow-up Comment #4, bug #35410 (project make): Well, personally I often use filter-out to intersect lists of variables, which can be rather big (about 2 variables) and contain more or less long names. old_variables := $(.VARIABLES) ... new_variables := $(filter-out $(old_variables),$(.VARIABLES)) ___ Reply to this item at: http://savannah.gnu.org/bugs/?35410 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #35410] [patch] Fix a bug with filter/filter-out functions when pattern contains only quoted percents
Follow-up Comment #5, bug #35410 (project make): I just don't believe the change will really save much. strlen() is pretty darn efficient and trying to circumvent it has costs as well. With modern compilers and architectures it's almost impossible to guess which sorts of micro optimizations, like this, will be effective. If you have any empirical numbers showing a significant difference I'll think about it. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35410 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #16545] Escaping a : in an escaped substition reference on a prereq line dumps core
Update of bug #16545 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS ___ Follow-up Comment #1: Fixed. If you don't escape the : it will still fail (right now we get an infinite loop so that needs to be addressed but that's a different bug) but without the escape it's not a legal syntax. ___ Reply to this item at: http://savannah.gnu.org/bugs/?16545 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #12126] Backslashes for escaping colons in dependencies are not removed
Update of bug #12126 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS ___ Follow-up Comment #3: The basic functionality is fixed: if you escape the colon it will work now. The return value of $(wildcard ...) is a whole other problem. The issue is we can't have wildcard always quote the colons in its return value because depending on the context you may not want the quote. This is similar to the problems we have with whitespace in filenames and I suspect that the solution, when we implement it, will encompass both. I think you can fake it by using subst to change a : to a : in situations where that's needed...? ___ Reply to this item at: http://savannah.gnu.org/bugs/?12126 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #31361] gcc.exe is deleting as file prematurely
Update of bug #31361 (project make): Status:None = Not A Bug Open/Closed:Open = Closed Summary: MinGW make inexplicably invokes as.exe = gcc.exe is deleting as file prematurely ___ Follow-up Comment #12: I updated the summary line. I have no idea what's going on but from what I see it's not a problem in make so I'm closing this bug. ___ Reply to this item at: http://savannah.gnu.org/bugs/?31361 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34542] vpath windows issues
Update of bug #34542 (project make): Status:None = Works for me Open/Closed:Open = Closed ___ Follow-up Comment #2: Closing as works for me. If anonymous comes by and updates the bug we can reopen. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34542 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #35485] New $(.MFDIR) built-in variable
Follow-up Comment #5, bug #35485 (project make): I don't think the stack-based approach is actually more runtime or space intensive ... I don't think so either. I just meant it would be a more intrusive change in terms of diff size than the one-liner proposed here. But if you're that it's not, this is good news. Although, I am not sure what I would like will be what you're looking for, because what I'd like to see is a variable containing the currently parsing makefile. I don't think we disagree that much. First, I don't care so much about whether the path is canonicalized, though I do kind of prefer it aesthetically. Second, it's true that a variable which evaluates to the currently parsing makefile would go a significant way toward addressing my concern. In other words I could live with it. That said, I don't think you've addressed the core of my point which is basically pedagogical. I think the directory of the current makefile is a fundamental concept, just as important to single-DAG systems as the current working directory is to process-recursive build models, and deserves to be treated that way. Yes, MFDIR could be derived easily from the current makefile, but that still leaves it a second class citizen. As noted, though, I could certainly live with the compromise. I can live with the current state of things too, for that matter, I just think it's a bit sub-optimal. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35485 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
