From: Ralf W. <Ral...@gm...> - 2005-11-15 14:03:49
|
* Keith MARSHALL wrote on Tue, Nov 15, 2005 at 01:59:37PM CET: > Ralf Wildenhues wrote: > [concerning Windoze vs. MSYS path name comparisons in libtool] > > Yes probably. Using w32 paths throughout has its share of > > problems, too. For example, it makes path concatenation (for > > DESTDIR) hard. ... > > For that, you would probably need a complementary macro, which > will map a native Windoze path to an MSYS virtual representation; > (hint: cd WindozePath && pwd); Ah, ok. > but note that, even then, you > would be likely to run into trouble with something like: > > C:/foo/bar --> /c/foo/bar > > because there isn't anything, except perhaps a UNC server > reference, which you can logically place before the /c drive > designation, unless you are willing to accept that you may > create a directory called `c', at a lower level in the > filesystem hierarchy. I don't fully understand; this ./configure --prefix=/usr/local make make install DESTDIR=/tmp/dest mv /tmp/dest/usr/local/lib/* /usr/local/lib should and will work fine for most packages. Right? Even if I replace /usr/local with /c/foo/bar, I assume this will remain true. Right? Keep the comments coming -- thanks for everyone else's as well -- there are more wrong ideas in my brain that need to be fixed. My lack of experience with mingw/msys shows, unfortunately. > > ... So for this alone, (since reverse mapping from the w32 > > path is hard), it would be better if pkg-config provided the > > unix-style path, if possible. Note also, your macro requires > > that the path exists ... > > No, it doesn't. It iteratively decomposes the given path name > argument, until it finds an initial base path which *does* exist, > converts that, and then reconstructs the original path name > relative to that converted base. D'oh. Sorry for that braino of mine. Yes, the macro is much smarter than I originally saw. Nice! Also sorry for the braino of assuming that pkg-config /could/ provide the unix-style path. That is not possible (without an msys hack, which I did not intend at all). So, a fix in Libtool is needed. I'll try to write one. But I really simply need the trace output and/or something reproducible (plus some time) to do it, and add a test to Libtool so it does not break again. Note also that Libtool *is* prepared for w32 paths in most cases already (judging by a number of special cases and the lack of bug reports ;). Cheers, Ralf |