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
