[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Work around a bug in Solaris make's file-inclusion mechanism
Re: [PATCH] Work around a bug in Solaris make's file-inclusion mechanism.
Fri, 16 Jul 2010 15:06:33 +0200
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )
At Friday 16 July 2010, Dave Hart wrote:
> On Thu, Jul 15, 2010 at 22:59 UTC, Stefano Lattarini
> <address@hidden> 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?
> I hope it's not rude for me to dive in from a lurking position.
Absolutely not, on the contrary, thanks for your answer.
> The "Why?" is ambiguous, but I can address the assumed question
> "why is initial double slash not the same as a single slash in
Yes, this was the intended question.
> There are likely systems out there where
> is equivalent to
> 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".
> That is, just like \\a\path\to\file would be interpreted by
> Windows' networking.
Thanks for the info.
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).
Ralf, are we sure we want to complicate the already complex automake
code to allow for such (ab)use of functionalities?