Hello there,
I am writing to you folks as I am wondering if a tool suite of ours
could make use of or contribute to libtool, automake and possibly
autoconf. The suite in question is called SRT, for Software Release
Tools; we use it in much of our software development. It is a set of
shell scripts to manage our software releases and builds. The build
parts of it are constructed on top of autoconf and GNU make.
As a backgrounder, we have some 170 software packages in a world-wide
distributed development environment. I would not be surprised if we had
~500 packages in a few years time. The code is stored in CVS in a
hierarchical package structure: packages can contain other packages, and
the entire release holds all other packages. Typically leaf packages
build the interesting products: libraries, executables, documentation
etc.
Out of this software base we roll out releases, currently every two
weeks. A release currently includes a tagged version of almost all
packages, built for all platforms we support (currently five unix
platforms). This amounts to a tree of about 3GB after `mostlyclean'
(~10GB peak) and takes 4-8 hours to build per platform (the platforms
are done in parallel). The releases are mirrored in a few places around
the world, either by copying the binary release, or by getting the
source and building locally. Recently there has been increasing mirrors
to laptops and CDs, and I expect this to become more common. The main
releases are on a world-wide networking file system (AFS = Andrew File
System) and the majority of the developers access the releases that
way. There is also a nightly release where we build the head version of
everything.
Obviously no developer ever wants to build the releases themselves. An
average developer has her own build area that is "based" on some
release. All the headers, libraries and programs that the developer
hasn't checked out to her own build area are looked up there.
A large majority of the packages build shared or archive libraries, but
the tools support the entire range of GNU coding standard products and
makefile targets. The code base is in FORTRAN 77, FORTRAN 90, C, C++,
plus some intermediate languages (age => FORTRAN 77 and C++, bison and
flex files, database schema descriptions => C++ etc.; java is now
starting to appear).
Another important bit of detail is that our developer base is, well, not
very sophisticated tools-wise. They won't give a hoot about learning
SRT, much less autoconf. They aren't your average GNU package
maintainer -- most of them can barely find their way around unix shell,
know next to nothing about make, and uttering `m4' will make them run
away screaming.
So, back to SRT. It currently implements functionality similar to
automake and libtool on about 20 different operating system/compiler
combinations, including LynxOS (a cross-compiler environment), Windows
NT/MSVC++ and IBM AIX, for all the languages we support. We use several
different compilers -- mostly native compilers -- not just gcc, and have
to jump through whatever hoops it means (and take advantage of things
like precompiled headers when they work). We also support various
options to the compilers -- the user can be specify "optimise",
"profile", "mt" and other such things to get specific sets. Another
complicating factor is that we also support build-process-modifying
compiler-like tools: Logiscope++, Insure++, Purify and code-checking
tools. These alter the build process -- sometimes very radically --
e.g. to instrument the source code before compiling it, or to gather
metrics instead of compiling the code. These tools are chosen at
`configure' time, and for some of them it is also possible at `make'
time.
A normal usage pattern is similar to an average GNU package: cvs
checkout, configure, make, edit, make, ..., make check, make install
(installing in /usr/local makes no sense in this scenario, so SRT
overrides default $prefix). SRT-provided autoconf macros take care of
locating packages, constructing -I, -L and -l option lists, recording
the state for make etc. SRT also provides a standard makefile body that
makes use of GNU make's special features to allow rather abstract
makefiles to be written. SRT makes an effort to be safe for parallel
makes and parallel multi-platform builds as any good GNU package should
be.
For an example, a typical `configure.in' would be something like:
AC_INIT(src/somefile.cxx)
SRT_INIT
SRT_CONFIGURE_LOCAL
SRT_OUTPUT(GNUmakefile)
and a typical `GNUmakefile.in' would be something like:
TARGET_SHLIBS = libfoo.so
libfoo.so_LINKSET = foo
libfoo.so_SRC = src/somefile.cxx \
src/otherfile.cxx \
src/data.F
include $(SRT_HOME)/standard.mk
and a corresponding `PACKAGE' file would go:
title foo -- a great library
author Me [EMAIL PROTECTED]
version foo-02-03-04:20000317185310
linkset foo -lib:foo
use bar 01-02-03 some/where
use c++
use f77
OK, don't worry about the details, but this should give you a rough
idea. This package would use `bar': get the -I options needed for and
by `bar' (transitively), link the shared library libfoo.so
(appropriately transformed to the shared library naming convention on
that plaform) with whatever libraries `bar' provides (and depends on),
install the libfoo.so in $(libdir). C++ and FORTRAN 77 would be used to
compile the source files as appropriate. It works the standard GNU
conventions way, i.e. you can build it in the source directory or from a
build directory.
One can have several targets in a single makefile, e.g. build a shared
and archive library out of the same sources, or build several
executables from the same source with different options or library
dependency chains, and SRT makes sure things don't get confused. Things
like -I options, what linker to use and what rpath to assign are decided
per-target.
Finally, my question. Thanks for reading this far! Do you think there
would be a possibility to integrate this tool suite somehow with
automake and libtool?
I would like to reduce our own layers to the minimum and help free
software if I can. Unfortunately, there seems to be some
incompatibilities, quite possibly due to my limited understanding. One
crucial issue for us is the large scale of our software: number of
packages, sheer number of lines of code, number of developers, the
geographical distribution.
I started out by not using libtool because it says it doesn't support
C++ and didn't seem to understand obscure compilers -- we absolutely
have to have C++, but on the other hand, we do not really need some of
the features libtool provides (at least as far as I know now). In SRT
we have all the support we need, but then it doesn't do everything
libtool does. Likewise, automake does similar things as our layer built
on GNU make, but my impression was that automake isn't quite as flexible
(especially when it comes to using non-GNU compilers), and some of the
must-haves for us -- $(wildcard) and $(shell) -- didn't seem to be
available.
A final point is that I should really be able to hide from our
developers as much as possible beasts like automake and libtool -- and
recently it has become rather evident that I should reduce the use of
autoconf and hide most of it. This is due to our user base. Educating
them to become GNU-savvy developers is not an option.
Basically, what I am after is a single tool suite that would go all the
way from configure (autoconf; for scripting) to makefiles (automake; for
abstract makefiles) to binary tools (libtool; for understanding
weirdities of systems and compilers). That doesn't mean that they have
to be all in one package, but they should integrate seamlessly. But it
does mean that -- as much as I myself like the tools! -- the range of
implementation mechanisms (m4, perl, make, sh scripts) is unproductive.
Thanks again for reading this far! Please let me know of any ideas you
have. Feel free to ask me any further questions! And please keep me in
Cc:s as I am currently subscribed only to the autoconf list. Thanks!
//lat
--
Do not meddle in the affairs of dragons,
for you are crunchy and good with ketchup.
