[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Automake for system libraries

From: Ryan Arnold
Subject: Automake for system libraries
Date: Mon, 06 Apr 2009 15:06:20 -0500


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's.  This has presented some problems.

Please forgive my lack of brevity.


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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]