Re: Automake for system libraries
Hello Ryan, * Ryan Arnold wrote on Thu, Apr 09, 2009 at 11:28:29PM CEST: Can you off-load the sysdeps detection into a couple of configure macros and replace the corresponding file names with AC_SUBST substitutions? You'd still have to list all possible files in some EXTRA_libdfp_a_SOURCES variable somewhere, but at least that would get you going. So I've been trying out the AC_SUBST substitutions like you suggested. configure.ac:324: `dfp_files' includes configure substitution `...@dfp_files@' configure.ac:324: and is referred to from `dfp_SOURCES'; configure.ac:324: configure substitutions are not allowed in _SOURCES variables Please see info Automake 'Conditional Sources' for details, vs. here: http://www.gnu.org/software/automake/manual/html_node/Conditional-Sources.html Cheers, Ralf
Re: Automake for system libraries
On Tue, 2009-04-07 at 23:12 +0200, Ralf Wildenhues wrote: * Ryan Arnold wrote on Mon, Apr 06, 2009 at 10:06:20PM CEST: 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. Can you off-load the sysdeps detection into a couple of configure macros and replace the corresponding file names with AC_SUBST substitutions? You'd still have to list all possible files in some EXTRA_libdfp_a_SOURCES variable somewhere, but at least that would get you going. Hi Ralf, So I've been trying out the AC_SUBST substitutions like you suggested. configure.ac: ... # This has main.c and helper.c computed from a sysdeps tree walk AC_SUBST(dfp_files) dfp_headers=helper.h AC_SUBST(dfp_headers) Makefile.am: ... dfp_source = $(dfp_files) $(dfp_headers) # filenames without a suffix. This is a local non-automake variable. dfp_SOURCES = $(dfp_source) Unfortunately autoconf automake are able to detect substitutions and it complains that this hack is forbidden: configure.ac:324: `dfp_files' includes configure substitution `...@dfp_files@' configure.ac:324: and is referred to from `dfp_SOURCES'; configure.ac:324: configure substitutions are not allowed in _SOURCES variables configure.ac:328: `dfp_headers' includes configure substitution `...@dfp_headers@' configure.ac:328: and is referred to from `dfp_SOURCES'; configure.ac:328: configure substitutions are not allowed in _SOURCES variables autoreconf: automake failed with exit status: 1 Any thoughts? Anyone else? Ryan S. Arnold IBM Linux Technology Center Linux Toolchain Development
Automake for system libraries
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
Re: Automake for system libraries
Hello Ryan, * Ryan Arnold wrote on Mon, Apr 06, 2009 at 10:06:20PM CEST: 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. 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. Well yes. Roland wrote GNU make, and glibc probably uses every single feature of it. Automake has little to no knowledge about GNU make- specific constructs. Can you off-load the sysdeps detection into a couple of configure macros and replace the corresponding file names with AC_SUBST substitutions? You'd still have to list all possible files in some EXTRA_libdfp_a_SOURCES variable somewhere, but at least that would get you going. Hope that helps for a start. Cheers, Ralf
Re: Automake for system libraries
On Tue, 2009-04-07 at 23:12 +0200, Ralf Wildenhues wrote: Hello Ryan, * Ryan Arnold wrote on Mon, Apr 06, 2009 at 10:06:20PM CEST: 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. 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. Well yes. Roland wrote GNU make, and glibc probably uses every single feature of it. Automake has little to no knowledge about GNU make- specific constructs. Can you off-load the sysdeps detection into a couple of configure macros and replace the corresponding file names with AC_SUBST substitutions? You'd still have to list all possible files in some EXTRA_libdfp_a_SOURCES variable somewhere, but at least that would get you going. Hope that helps for a start. Hi Ralf, I did indeed consider this as an option, but hadn't considered the EXTRA_libdfp_a_SOURCES, which is a good piece of the puzzle. I already use configure macros to determine the relevant search path for each platform-processor-encoding combination. I guess I'll have to list the target file names (sans suffix) in the configure fragments as well. This will require a configure fragment for each convenience library I suspect. Ryan S. Arnold IBM Linux Technology Center Linux Toolchain Development
