My apologize for sending this to two lists but I am having some trouble
separating these issues,
I am wrestling with some issues with regards to the
automake/autoconf/libtool (AAL) toolset and wanted to present them to
you all for some input (if you would be so kind).
I have been hired by NCSA to breakup and repackage a software project
called globus. The project already uses autoconf but it contains 123
different configure.in scripts and can only be built as one huge
package. I am trying to integrate automake and libtool into this
project.
There are two issues.
The first issue is: Where should the common configuration information
needed to build the various subpackages be stored?
I would like to set up a base package for the project which includes all
of the necessary configuration info (headers, script functions, macros
etc). All of the other packages would then include these base files to
avoid redundant configuration code. The project would also build a lot
faster.
With the existing AAL tools my configuration information comes either
directly from the AAL's /share directories or it is re-determined
individually by each package during tool execution. Examples:
- If automake determines that a file is missing, it pulls it from its
own /share/automake directory. ( I sent a patch for this a while ago
http://sourceware.cygnus.com/ml/automake/2000-02/msg00008.html)
- automake forces me to configure libtool for every package. I cannot
use a configured libtool installed in a base package.
- autoheader automagically defines the PACKAGE and VERSION variable in
every config.h file making it impossible for packages to cleanly include
more than one config.h file.
The second issue is: What to do about "flavors"? Globus delivers the
same library in multiple binaries that are built with different
configuration options. Examples of flavors include (--with-threads, and
32/64 bit integers). Currently Globus gives each flavor of a library
the same name but stores it in a different directory.
I am of the belief that I am going to have to make some changes to
automake and/or libtool to solve these issues. I would like to avoid
publishing rogue versions of these tools and so my quesions are this:
1. Do I need to sign anything to work on these tools? I already have
contribute permission from NCSA.
2. Is there something else that I can read concerning the overall
design of these tools? I have already studied the info pages from the
CVS archives. ( multi-language branch in libtool).
3. Would it be possible for me to have someone to pester with
questions so that I don't violate some design paradigm that would
prevent my patches from becoming accepted?
Thanks in Advance
Michael
------------------------------------------------------------------
Michael Bletzinger Software Developer, Alliance Computational
[EMAIL PROTECTED] Environment & Security
217 265 5137 NCSA
