Gunnar Ritter <[EMAIL PROTECTED]> wrote:
> > > _If_ they claim that. Otherwise they rely on documented behavior of
> > > GNU make. This is quite different from "the authors implement code
> > > that matches GNU make bugs", as you were writing previously.
> > The GNU make documentation claims that $< is the name of the first
> > dependency.
> >
> > This is not complatible with the POSIX standard which defines $< to be the
> > name of the implicit source that caused an iplicit rule inference rule)
> > to be chosen.
>
> The exact text in the "info" documentation for GNU make 3.80 is
>
> | `$<'
> | The name of the first prerequisite. If the target got its
> | commands from an implicit rule, this will be the first
> | prerequisite added by the implicit rule (*note Implicit Rules::).
>
> It could be more precise but I do not see a conflict here. The first
> sentence refers to the behavior unspecified by POSIX, and the second
> sentence adds the POSIX behavior.
Even then it would be wrong.
- Depending on the order of the prerequisites in makefiles
only works in small hand written Makefiles. If you use
structured makefiles or makefiles that have been created by
makefile generators, this is highly error prone.
- The second sentnce is just in violation with POSIX.
POSIX implicit rules are .SUFFIX: rules only a for this reason only have a
target that is a concatenation of source and target suffix. There is no
prerequisite but only an implicit target and an implicit source.
It may be that someone from the GNU folks did like to do something for
Sun Pattern matching rules:
tp%ts:dp%ds
rule
(this variant is implemented by smake also).
and this variant of the Pattern matching rules from Sun:
tp%ts:[dependency_1 ...] dp%ds [dependency_x ...]
rule
(this variant is not yet implemented by smake).
This variant seems to be implemented by GNU make also. But then, the implicit
source would not be the prerequisite #1 but could be at _any_ offset in the list
(see the definition above).
BTW: Smake locates the implicit source as "prerequisite #0" and the explicit
prerequisites starting from #1.
So what GNU make does, does not match POSIX and cannot match what GNU make
likes to implement.
> I apologize, but the amount of typos in your texts and the sheer noise
> you make about alleged GNU bugs even if all what you have is suspicions
> (such as in the discussion about blocking of cpio archives in RPM files
> we had on the GNU bug-tar list a few months ago) makes it hard do detect
> when you are actually correct.
Well having typos in a text is not as bad as writing incorrect text as you
seem to do a stypos usually look strange and thus should result in questions.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
