Automake for system libraries

[Ryan Arnold]

Greetings,

I'm attempting to port a GLIBC add-on I wrote (libdfp) into a standalone
library.  My plan is to auto-confiscate the GLIBC-esque Makefiles into
Makefile.am's.  This has presented some problems.

Please forgive my lack of brevity.

Background:

Libdfp is a system library that is the equivalent of libm for decimal
floating point data types.  It supports PowerPC (with DPD DFP data-type
encoding for both hardware dfp and soft-dfp) and x86 (with either a DPD
or BID DFP data-type type encoding (per IEEE754r)).

To accommodate platform/processor/encoding permutations in GLIBC, there
is a generic C-file implementation of everything, e.g. glibc/file.c.
Then there may be base-platform specific overrides in a sysdep tree,
e.g. glibc/sysdep/powerpc/powerpc32/file.c.  There may also be processor
specific overrides that are handwritten in assembler, e.g.
glibc/sysdep/powerpc/powerpc32/power6/file.S.

In GLIBC Makefiles we indicate which source files we want, sans suffix
(.c or .S), e.g. "file" and then the build system uses a VPATH mechanism
to find a matching .S or .c file based on a search order through the
sysdeps tree and base src tree.  It picks up the first (deepest)
instance of file.[Sc] it finds.

Moving from GLIBC's very robust and complicated handwritten Makefiles
(written by Roland McGrath) to Automake has proven to be conceptually
difficult while trying to maintain the sysdeps tree structure.

I tried using $(wildcard pattern) to build the dfp_SOURCES list
dynamically (by having some rules search through the Autoconf computed
valid/relevant branches of the sysdeps tree) but quickly found out that
`wildcard' ist verboten, and in-fact dynamic SOURCE file identification
is strongly discouraged.

I can't see a simple way to make robust architecture specific file
overrides and assembly file optimization overrides in Automake.

I'd like to keep the sysdeps layout in-case the GLIBC maintainer has a
change of heart if the draft C-spec is ratified.  I think I can still
use the convenience library mechanism to some extent, even if I merge
back upstream.

I really hope the simplicity of Automake can work for me since I don't
find the complex task of recreating GLIBC's complex build system by hand
very appealing.

Does anyone have any suggestions (no matter how small) on how to
implement a sane Automake build system for a system library given the
platform/processor/feature permutations described above?

Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development