On Fri, Jun 6, 2008 at 5:49 AM, <[EMAIL PROTECTED]> wrote:
> All is well:
> $ cat Makefile
> all:z.bak
> %.bak:;
> $ make
> make: Nothing to be done for `all'.
> Until we add a %:
> $ cat Makefile
> all:z.bak
> %.bak:%;
> $ make
> make: *** No rule to make target `z.bak', needed by `all'
On Fri, 2008-06-06 at 19:49 +0800, [EMAIL PROTECTED] wrote:
> All is well:
> $ cat Makefile
> all:z.bak
> %.bak:;
> $ make
> make: Nothing to be done for `all'.
> Until we add a %:
> $ cat Makefile
> all:z.bak
> %.bak:%;
> $ make
> make: *** No rule to make target `z.bak', neede
OK, OK, is perhaps this message,
make: *** No rule to make target `z', needed by `a'. Stop.
is actually triggered by several different conditions, and could instead
be refashioned into several more exact messages, e.g., no rule at all,
no best rule, etc.
___
On Mon, 2008-06-09 at 11:28 +0800, [EMAIL PROTECTED] wrote:
> OK, OK, is perhaps this message,
> make: *** No rule to make target `z', needed by `a'. Stop.
> is actually triggered by several different conditions, and could
> instead be refashioned into several more exact messages, e.g.,
PS> I don't understand the distinction you're making here between "no rule
PS> at all" and "no best rule" (what's a "best rule"?), and just "no rule".
Maybe whatever prints messages prefixed by
make: *** No rule to make target
is called from several different points in the code, and could give
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 betw
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
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;
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
