|
Message-Id: <20121128120341.ca114e90.idunham@lavabit.com> Date: Wed, 28 Nov 2012 12:03:41 -0800 From: Isaac Dunham <idunham@...abit.com> To: musl@...ts.openwall.com Subject: Re: Design idea for subarchs/abivariants On Wed, 28 Nov 2012 14:26:18 -0500 Rich Felker <dalias@...ifal.cx> wrote: > The problem: how to have subarch variants on the bits headers and asm > for a given arch without ugly build system complications or massive > duplication of files. > > Proposed solution: > > 1. $(ARCH)$(SUBARCH)/%.s is searched in addition to $(ARCH)/%.s for > arch-specific files replacing general %.c files in the src tree. This > would allow src/fenv/arm-hf/%.s and src/setjmp/mips-sf/%.s files, for > example. > 2. Making bits/endian.h, bits/fenv.h, and any other bits headers that > need to vary per-subarch into generated headers. <snip> > 3. Having configure derive separate $(ARCH), $(ENDIAN), and $(SUBARCH) > from the gcc-style machine strings or combined musl-format arch string. > Comments? Seems fairly clean to me, though I'd been thinking of a variant of 1: $(ARCH)/$(SUBARCH)/%.s (on the premise that anything that gets used for an arch should be in one place). But now that I think about it, I'm not certain that's a meaningful advantage, and with your approach, */<file>.s is going to get every appropriate file. By the way, while we're on the makefile: in the past, I've run into issues with cycles like: make <forget to check for builds> git pull # or git checkout .... make clean # doesn't handle files that were moved/deleted make # link breaks, due to remaining oject files I usually do this to cleanup in such cases: find src arch -name '*.*o' |xargs rm Would adding some similar logic be sensible (at least for the distclean target)? -- Isaac Dunham <idunham@...abit.com>
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.