>>>>> "Michael" == Michael Bletzinger <[EMAIL PROTECTED]> writes:
Michael> The first issue is: Where should the common configuration
Michael> information needed to build the various subpackages be
Michael> stored?
It depends on your goals.
Michael> I would like to set up a base package for the project which
Michael> includes all of the necessary configuration info (headers,
Michael> script functions, macros etc). All of the other packages
Michael> would then include these base files to avoid redundant
Michael> configuration code.
Sounds like you want to use config.cache to speed up the configuration
process.
Some packages, like Gtk+, create a script which encodes the
configuration information it discovered. Then users of the package
can use this script's output to find the answers quickly.
Michael> - automake forces me to configure libtool for every package.
Michael> I cannot use a configured libtool installed in a base
Michael> package.
You might be able to make this work somehow, but I don't know it
offhand.
Michael> - autoheader automagically defines the PACKAGE and VERSION
Michael> variable in every config.h file making it impossible for
Michael> packages to cleanly include more than one config.h file.
Use the (documented) 3rd arg to AM_INIT_AUTOMAKE to disable this.
Michael> The second issue is: What to do about "flavors"? Globus
Michael> delivers the same library in multiple binaries that are built
Michael> with different configuration options. Examples of flavors
Michael> include (--with-threads, and 32/64 bit integers). Currently
Michael> Globus gives each flavor of a library the same name but
Michael> stores it in a different directory.
You can already do this. We do this with runtime libraries for the
compiler, where it is called "multilibbing".
You can make the install directory depend on configuration options in
several different ways.
Michael> 1. Do I need to sign anything to work on these tools? I
Michael> already have contribute permission from NCSA.
If you make significant changes you have to sign paperwork for the
FSF.
Michael> 2. Is there something else that I can read concerning the
Michael> overall design of these tools?
For automake, no.
Michael> 3. Would it be possible for me to have someone to pester
Michael> with questions so that I don't violate some design paradigm
Michael> that would prevent my patches from becoming accepted?
For automake, ask the list. I won't always have time to answer, but
other people probably will.
Tom
