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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.