[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
