Date: Wed, 28 Nov 2012 18:57:45 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Design idea for subarchs/abivariants On Wed, Nov 28, 2012 at 12:03:41PM -0800, Isaac Dunham wrote: > 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. I don't have a lot of preference one way or the other. I'd probably use $(ARCH)/$(ARCH)$(SUBARCH) though, since $(SUBARCH) is likely to be an awkward string like "-sf" that's ugly and error-prone as a directory name (easily misinterpreted as an option). > 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 This is not possible. Spurious *.o files lying around do not get used whatsoever in the build process, for the exact same reason that they do not yet deleted by "make clean". > I usually do this to cleanup in such cases: > find src arch -name '*.*o' |xargs rm There are no .o files under arch. It's purely headers. > Would adding some similar logic be sensible (at least for the > distclean target)? I'm a little bit hesitant to delete files that we didn't create. This could lead to deleting a file that somebody did not want deleted, which I really don't want to be responsible for.. Rich
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.