[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
Mon, 12 Sep 2005 11:13:50 -0700
On 9/6/05, Ralf Wildenhues <address@hidden> wrote:
> Hi Travis,
> * 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
> > environment.
> Just curious: What's the motivation behind gathering this information
> (except for knowing how to build)?
The idea behind our application is to gather build information and
other data pertaining to the execution of the user's program. Then we
can measure how well an application executes on one architecture
compared to another, how well it performs when more nodes are thrown
at it, how the use of different libraries effect the program's speed,
how the use of different compiler speed up or slow down the resulting
program, and this soft of thing.
> 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.
Unfortunately, I can't mandate that all users of our program must
autotool their applications. Many of our primary users aren't
computer scientists or software engineers; they are physicists,
biologists, and mathematicians first and programmers second.
> One cheap way would be to reuse/parse that, or to
> add your own output files which then contain the necessary information.
This suggestion is what I'm leaning toward. This is my current idea:
We write a configure.ac file that contains the macros we need (e.g.,
check for a C, C++, Fortran compiler, etc.). Unlike normal, the
output will not be a Makefile, but rather, it will produce a script
using some input of our making (e.g., `capturebuild.in'). (This may
sound odd, but bear with me.) This script will be contain such things
as `@@CC@@', `@@CXX@@', etc. Then, our users would run configure, and
these variables would be replaced with the name of the compiler they
would like to use. Finally, the user runs our script which invokes
make to build the user's program. Knowing what a compiler command
looks like based on the information gathered from `@@CC@@' and such,
make's output could be grepped through to find which compilers compile
which source code.
This sounds plausible to me, but I'm still very green. I can see how
this would work for finding information about compilers, linkers, and
assemblers, but I'm not sure how this would work to discover which
libraries were built.
> Don't hesitate to ask for more specific information.
Thanks for your willingness to help and listen to me cyber-extrovert, Ralf.