RE: File timing bug
Hi, Perhaps due to my long and annoying description, one has difficulty in understanding what the problem I encountered was. Here I would provide a much shorter description. GNU Automake generates dependency tree like this in Makefile.in: [EMAIL PROTECTED]:~/tmp/k$ cat Makefile a: b cat ba b: c c: d dateb cp b c [EMAIL PROTECTED]:~/tmp/k$ Its intention is to regenerate `a' when `d' is updated. But this does not work, since it requires `make' to be executed twice: [EMAIL PROTECTED]:~/tmp/k$ make dateb cp b c [EMAIL PROTECTED]:~/tmp/k$ make cat ba [EMAIL PROTECTED]:~/tmp/k$ However, I noticed that if the Makefile looks like this: [EMAIL PROTECTED]:~/tmp/k$ cat Makefile a: b cat ba b: c cp c b c: d datec [EMAIL PROTECTED]:~/tmp/k$ Everything works as expected: [EMAIL PROTECTED]:~/tmp/k$ touch d [EMAIL PROTECTED]:~/tmp/k$ make datec cp c b cat ba [EMAIL PROTECTED]:~/tmp/k$ Is this a bug in GNU make, or a bug in GNU Automake? Regards, Guanpeng Xu _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. No rule to make target
On Mon, 2008-06-09 at 12:02 +0800, [EMAIL PROTECTED] wrote: Maybe whatever prints messages prefixed by make: *** No rule to make target is called from several different points in the code, and could give finer grained messages, all still on one line. Maybe there is a difference between no rule at all and yes, a few rules, but no best one. Like, no wires at all found and yes found some wires, but none that could complete the circut and several paths to complete the circut, but no best path, so giving up. There is no several rules but no best rule. In make, the very first matching rule it finds that works is considered the best rule; only if there is no matching rule at all do you get this message. I suppose it would be possible to make a distinction in the output between a situation where no rule that matched the target was found and one where an implicit rule matched the target, but couldn't be used. However, I don't know what helpful information that really gives you. Plus, there would be no way you'd ever get the no rule matched the target message unless you had customized your makefile to remove the built-in rules, because there are a number of match anything built-in rules, that match ALL targets. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. No rule to make target
Do differentiate error messages from different triggers, all in preparation for a perl-like See perldiag for explanations of all Perl's diagnostics. The use diagnostics pragma automatically turns Perl's normally terse warnings and errors into these longer forms. hand holding facility for make, ten+ years down the road. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: File timing bug
This example is certainly simple, thanks. The Makefile isn't telling make that the rule for making c from d will also update b. Make caches modification times and doesn't know to invalidate its cache of b's time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herbert Euler Sent: Monday, June 09, 2008 02:36 To: bug-make@gnu.org Subject: RE: File timing bug Hi, Perhaps due to my long and annoying description, one has difficulty in understanding what the problem I encountered was. Here I would provide a much shorter description. GNU Automake generates dependency tree like this in Makefile.in: [EMAIL PROTECTED]:~/tmp/k$ cat Makefile a: b cat ba b: c c: d dateb cp b c [EMAIL PROTECTED]:~/tmp/k$ Its intention is to regenerate `a' when `d' is updated. But this does not work, since it requires `make' to be executed twice: [EMAIL PROTECTED]:~/tmp/k$ make dateb cp b c [EMAIL PROTECTED]:~/tmp/k$ make cat ba [EMAIL PROTECTED]:~/tmp/k$ However, I noticed that if the Makefile looks like this: [EMAIL PROTECTED]:~/tmp/k$ cat Makefile a: b cat ba b: c cp c b c: d datec [EMAIL PROTECTED]:~/tmp/k$ Everything works as expected: [EMAIL PROTECTED]:~/tmp/k$ touch d [EMAIL PROTECTED]:~/tmp/k$ make datec cp c b cat ba [EMAIL PROTECTED]:~/tmp/k$ Is this a bug in GNU make, or a bug in GNU Automake? Regards, Guanpeng Xu _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. No rule to make target
On Tue, 2008-06-10 at 01:49 +0800, [EMAIL PROTECTED] wrote: Do differentiate error messages from different triggers, I'm not sure this is fruitful, but to reiterate: there are no different triggers. There is one procedure. It looks something like this (100% psuedo code): rule *r; r = find_explicit_rule(target); if (r) return run_rule(r); r = find_implicit_rule(target); if (r) return run_rule(r); error(No rule found to create %s, target); I guess what you're suggesting is something like: rule *r; int possible_rules; r = find_explicit_rule(target); if (r) return run_rule(r); r = find_implicit_rule(target, possible_rules); if (r) return run_rule(r); if (possible_rules == 0) error(No explicit rule found to create %s, target); else error(No implicit or explicit rule found to create %s, target); I just don't see the point. Even ignoring the fact that you'd never see the message from the then part of the error statement (because by default there plenty of rules that match any possible target), what does this information do for you? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. No rule to make target
PS what does this information do for you? I don't know, all I am thinking is hooks (i.e., differing error messages that can be post processed by:) for a future hand holding system so one can ask what went wrong? And have super basic tutorial information given... (target implementation date 2050, implementor: some fellow like the one who wrote the Bash Advanced guide or Emacs Lisp big manual.) (Just make slightly differing messages if they can be made today without rearranging the program just for this.) I guess what you're suggesting is something like: I don't know, it's all over my head anyway. OK, thanks. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
