Re: [PATCH] Work around a bug in Solaris make's file-inclusion mechanism.

[Ralf Wildenhues]

Hi Stefano,

<http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/4893/focus=4276>

* Stefano Lattarini wrote on Fri, Jul 16, 2010 at 03:06:33PM CEST:
> At Friday 16 July 2010, Dave Hart wrote:
> > On Thu, Jul 15, 2010 at 22:59 UTC, Stefano Lattarini wrote:
> > > At Thursday 15 July 2010, Ralf Wildenhues wrote:
> > >> No, the patch should not modify initial double slash, that is
> > >> not the same as a single slash in general.
> > > 
> > > Why?

> > There are likely systems out there where
> > 
> > /a/path/to/file
> > 
> > is equivalent to
> > 
> > //a/path/to/file
> > 
> > but on some systems the two refer to different namespaces, with
> > //a/path/to/file being a reference to file "file" in directory "to"
> > on share "path" of fileserver "a".

> Given the information Dave provided, it seems to me that the only way
> a leading `//' could be problematic for the automake code in question
> is when a file path specified in a prog_SOURCES begins with `//' (and 
> this path must be put there directly and explicitly by the Makefile.am 
> author, since the content of prog_SOURCES must be literal and not e.g. 
> substituted by configure).

Or by some user trying to hack our dependency tracking mechanisms.
Even if the code does not trigger in this case, the day will come when
somebody copies that code to use it on another case where it may
trigger.  We may not be around to watch.

> Ralf, are we sure we want to complicate the already complex automake 
> code to allow for such (ab)use of functionalities?

Yes, we would like to treat file names consistently.  Consider factoring
out complex issues into their own well-defined functions to avoid
needless complexity.

Thanks,
Ralf