Re: Summer of Code

[Martin d'Anjou]

Hi John,

> Hello! Sorry for the delay...
>
> I read your e-mail, your blog post, the message from Paul Smith and 
> your patch proposal (in the link you gave sent [1]), and it seemed a 
> nice thing to do. The only problem is: is this really so big that 
> would take me two or three months to do? I know I may be 
> underestimating the amount of trouble I can get when changing the code 
> here or there, but I am really not sure that this would be so 
> difficult to change.
>
> Also, I didn't understand if this is really something that should 
> definitely be done. Reading the bug list for the last months made me 
> see that some bug proposals simply receive the "won't fix" answer and 
> are discarded. I agree that this seems to be an interesting 
> improvement to make (as well as another proposal I've seem some days 
> ago about the "-j" option, that charges the cpu indefinitely and can 
> end up freezing everything -- what wouldn't be nice to me, if I'm 
> playing Gnomines while my program is builded), but I really need to 
> know if everyone agrees that someone shall do this (otherwise, I'll be 
> wasting my time doing something that won't be "accepted").
>
> Anyway, I really appreciate your idea!
>
> [1] http://lists.gnu.org/archive/html/bug-make/2009-01/msg00035.html
> --
> John Gamboa
> rabanetescebolas.blogspot.com <http://rabanetescebolas.blogspot.com>


Please don't forget to CC the list, as it is the only way the other 
users can inform us on the importance of these ideas to them, and I can 
certainly not speak for them!

You are right, this is not a 3-month long project, but I also assume 
that the GNU Make maintainers have requirements that must be met for the 
patch to be accepted in term of automatic unit tests and playing nice on 
the different OSes, and for that I do not know how much time is 
required, probably not very long but still it could be a couple of weeks.

Okay, so two more ideas:

1) Have a way for the parent to pass the value of its stem to a child rule

If the child rule knew what the parent stem was, it could utilize the 
parent variables in its commands, as shown here:
http://lists.gnu.org/archive/html/help-make/2011-07/msg00050.html

2) Improve the no rule to make target error message

A common complain with GNU Make is how dry the "no rule to make target" 
error is. This message is annoying because it is like a seg fault: you 
must rerun with the debug switches to be able to tell what caused the 
problem, and you must also possess a PhD in Makefile-o-logy to interpret 
the trace you get. If GNU Make could print a minimalistic "stack trace" 
of what leads to the  error and filter out all the non-relevant stuff, 
this error would be more approachable for the non-make people.

Thanks for your interest!
Martin