Re: Summer of Code

[John Gamboa]

Hello,

> 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!
Oh, yeah, sorry, and thanks. I didn't notice that I was sending the
e-mail just to you. In fact, I just clicked in the "white box" in
Gmail and didn't pay attention to who I was sending my e-mail to.
Sorry for that.

> 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.
Ok, so, now that I've seen the timeline decently [1], I have to say
that it seems (of course, if I am selected) that I'll have 4 months to
do whatever I propose.

> 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
I have to say I'm not sure if I understood this problem. I'll try to
read more and find more information on this problem and I believe
tomorrow I'll be understanding it better.

> 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.
This is a GREAT Idea! A proposal in which I had not though and that
could surely bring some really nice improvements to make! (or, at
least, this is my opinion). I had already falled in these "no rule to
make target" things one or two times, and the only way to debug I had
was my own Makefile and my "feeling". Anyway, since I don't know how
make is implemented and how its code works in its internals, I really
don't know how much time it would take to make it to work. Do you
think this would be a good proposal "per se" (i.e., just this would be
enough as a proposal)? Or do you think I should just turn this as yet
another item in a proposal?

I have just another question: if I really submit my proposal for the
GNU project with a project for GNU Make, is there any chance for me to
be accepted? I ask this because, so far, as far as I can tell, my only
feedback about my chances in GSoC in GNU Make is from an user, like me
(at least you called yourself just a user, right?), and I feel like
creating expectations without being sure even of the minimal things.
So, if there is no chance, I'd like to be warned as soon as possible.

Anyway, really thanks for your sugestions :-)

[1] 
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs#timeline

-- 
John Gamboa
rabanetescebolas.blogspot.com