[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121128235745.GT20323@brightrain.aerifal.cx>
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.
