[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Wondering if libtool can be adapted, ported, or used to solve my pro
Re: Wondering if libtool can be adapted, ported, or used to solve my problem
Tue, 6 Sep 2005 13:06:50 +0200
* Travis Spencer wrote on Sat, Sep 03, 2005 at 12:02:15AM CEST:
> I am working on a research project at Portland State University that
> involves writing an application that will build its user's source code
> and gather a lot of information about the build process and host
Just curious: What's the motivation behind gathering this information
(except for knowing how to build)?
> A partial list of information that I'm trying to gather
> includes the following:
> Like any good OSS developer, I'm trying to find an application that
> can already do something similar in hopes that I can adapting it to
> suit my needs. It seems that libtool may be a good candidate, but I'm
> not very familiar with it. I'm hoping that those on this list who are
> can tell me if its worth more investigation.
For packages that use libtool consistently, a lot of information may be
gathered from it, probably most that you need. Similarly, for packages
that use Autoconf and maybe Automake: even if they don't produce shared
libraries, you will be able to gather most information from them.
> In section 5.3 of the libtool manual, it says "Libtool requires
> intimate knowledge
> That is basically the information I need: intimate knowledge about the
> compilers, OS and libraries used to build a user's code.
> I can't make many assumptions about the build environment because my
> application needs to run on numerous OSes (Solaris, Linux, AIX, and
> more), must support multiple compilers (gcc, Forte, Intel, PGI, MPI,
> etc.), and needs to know information about static and dynamic
> libraries which (as you all know) are handled differently on some of
> these OSes. The great number of factors and unknowns is very
Yes, it is. :-)
> Somehow libtool manages it though.
Libtool mostly through lots of gathered data points. Autoconf otherwise
tries to test for features, and uses this approach to also cope to some
extent with yet-unknown systems.
> Do you think it can help me overcome these obstacles too?
Some at least.
> If you need more info or if I wasn't clear enough in my explanation,
> please let me know, and I'll try to clarify.
Well, to get you going with things: with autotooled projects, the
configure script usually does all the magic of finding out what the
subsequent build process needs to know: compiler, flags, utility names,
header files, whatever. This gathered knowledge is coded in some
substitutions in generated files, for example the built Makefiles, the
libtool script (look at `./libtool --config --tag=CXX', for example),
and other outputs. One cheap way would be to reuse/parse that, or to
add your own output files which then contain the necessary information.
For software that does not use the Autotools, this won't help you,
though (and surely software may use them, but either not consistently,
or it may override certain aspects of it because of limitations).
If you need further details, not only about the generated data but also
the way it is generated, there's the steep way into the m4 macro files
(like libtool.m4) which provide the basis for the configure script.
They'll be a bit scary at first, but the structure will become more
evident over time. In any case, the manuals of all three of Autoconf,
Automake, and Libtool provide very helpful information.
Don't hesitate to ask for more specific information.