Hi Bjoern,
On 2011-12-05 at 12:42 +0100, Bjoern Michaelsen wrote:
> Well, there is a good reason for paths in GNU make to be unix-paths. You
> define
> a rule as:
>
> C:B
> true
>
> for target C depending on B. If you use windows native paths something like:
>
> C:B:D
> true
>
> is valid and can mean either target C depending on target B:D or target C:B
> depending on target D.
So of course, it is not a Windows-only problem; you can very well have a
Unx path containing a ':' too. In a Makefile, you can escape it with
'\', and it works just fine; so if we defined the OUTDIR as C
\:/ugh/blah, we might (TM) be fine.
> IIRC there are some heuristics in the DOS/Windows native
> version GNU make, but I am not even sure if cypath has those too (and as this
> is a cornercase: if they are reliable). Also, it is not only make itself that
> has to take care of this, but also the little Perlhelpers etc that fiddle with
> this. IMHO, keeping the paths unixy is the safest bet.
Well - I'm just aware of the growing amount of
ifeq($(OS),WNT)
something $(shell cygpath -m $(OUTDIR)/ugh)
else
something $(OUTDIR)/ugh
endif
which makes the buildsystem overall ugly ;-) But yeah, I'm not going to
attempt to clean that up short-term, so probably let's let this
gbuild/build.pl unwanted interaction as a warning that this might
potentially bite us at some stage again.
Regards,
Kendy
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
