Re: Absolute paths generated by libtool.

[Benoit Sigoure]

Quoting Ralf Wildenhues <address@hidden>:

> Hello Benoit,

Hi, thanks for your quick reply.

> * Benoit Sigoure wrote on Tue, Nov 14, 2006 at 05:35:03PM CET:
> > My final questions are: is this necessary on Windows? Can't you keep the
> > relative path?
>
> Not easily.

That's weird though because if you look closely at the line printed by 
libtool,
it reads:
../behavior-graphs/src/.libs/libfsm.a
/home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a
../behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a
Note that the libfsm_xml_parser is printed twice, once with an absolute path
(which I don't want) once with a relative path (which I do want).

Now I really have no idea about libtool's logic and internals but here is an
educated guess:
libtool is invoked with the relative paths to the two .la. It reads them in
order to know what are the dependencies. The libfsm.la depends on the
libfsm_xml_parser and has the following in its .la:
dependency_libs='
/home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/libfsm_xml_parser.la
-Lc:/Qt/4.2.1/lib -lqtmain -lQtXml4 -lQtGui4 -lQtCore4'

Here is the address@hidden full path. Now libtool recursively reads the
libfsm_xml_parser.la and adds the absolute path to the .a.

Next, libtool treats the other .la it was given on the command line -- which
turns out to be the same as before (for libfsm_xml_parser) which leads it to
add a relative path to libfsm_xml_parser.a (because the .la was 
provided with a
relative path).

Alright so I see two possible ways out:
Before finalizing the command, libtool looks at all the libs and finds 
out that
libfsm_xml_parser.a appears twice (once with an absolute path and once with a
relative path) and preferes to drop the one with the absolute path. This is
non-trivial to implement (knowing that two different paths point in 
fact to the
same file) and requires more efforts.

Another solution would be: why not encode the relative path to
libfsm_xml_parser.la in libfsm.la ? After all, where does this path come from?
The Makefile.am says that libfsm.la LIBADD is xml_parser/libfsm_xml_parser.la.
Why not keep a relative path? Given the path to libfsm.la, we can find that of
libfsm_xml_parser.la using a simple concatenation. This is reasonably easy to
implement, isn't it? It requires very little changes and is not likely 
to break
anything right? (I'm not a libtool expert so I'm just guessing this, I 
know that
libtool internals are rather obfusc^H^H^H^H^H^Hcomplicated).

What do you think about this?

--
SIGOURE Benoit aka Tsuna
  _____
 /EPITA\ Promo 2008, LRDE