Re: Design idea for subarchs/abivariants

[Rich Felker <dalias@aerifal.cx>]

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@aerifal.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