[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 27 Jan 2016 16:04:57 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Bits deduplication: details/build system mechanisms?
I think it looks okay to have a simple full-file overlay for the first
phase of the bits deduplication. If we need more fine-grained dedup we
can look at more advanced approaches later. So the big question left
is how to actually do this in the build system.
What we'll have in the source tree is something like:
arch/$(ARCH)/bits/*.h
arch/generic-*/bits/*.h
arch/generic/bits/*.h
in that fallback order. I've intentionally left the second item vague
because there's some question of how we implement it. The possible
list of generic-* dirs we could have is:
generic-ilp32
generic-lp64
generic-ld64
generic-ld80
generic-ld128
generic-le
generic-be
generic-mips
The idea of generic-mips is that, if we add mips64 and possibly n32,
there are a lot of wacky mips-specific constant values that are shared
by them all.
I don't think it's worth actually having generic-le and -be because
the logic to search these dirs would be larger than the one line in
bits/endian.h.
It probably also doesn't make sense to have generic dirs just for long
double format, especially since archs that vary in float.h might also
have to define different FLT_EVAL_METHOD values. Then ld64 can just be
in generic and the few archs with ld80 or ieee quad can provide their
own (possibly duplicate, but tiny) versions.
One option to start would be not to have any generic-* dirs, just a
single generic. This would be easy to implement, but I really want to
be able to represent some of the genericness of things like the 64-bit
bits/socket.h hacks. Maybe we can do this in two phases, though, since
there are only a couple 64-bit archs so far and dedup'ing them isn't
the first priority.
Now, how to make the build system handle this all?
The first big question is whether to use multiple -I's at build time
and multiple implicit rules to control which bits files get installed
at install time, or to stage bits headers in obj/include/bits first.
The benefits of staging are that we avoid adding a bunch of new -I's
to every invocation of the compiler, and have more flexibility in how
we write the rules to pick the files. If obj/include/bits/*.h just
depend on all possible files they could be generated from, the actual
rule can contain the logic to select the first matching version.
There's also the flexibility to add more complex generation in the
future.
The disadvantage of staging is that it becomes hard to do any tests
that rely on bits headers from configure, since they haven't been
generated yet. Right now the only test that actually matters is the
check for incorrect long double on powerpc, and we could just remove
it because there's a second check at the source level during build,
but it's kind of nice to have the early check too.
If we don't stage but instead use -I's, or even if we do stage but let
the make control the choice of version copied via overlaid implicit
rules, then make somehow needs to be told about which generic dirs to
use. (Of course this issue does not apply if/as-long-as we only have
one generic dir.) I don't see any really clean way to do this aside
from something like
-include $(srcdir)/arch/$(ARCH)/generics.mk
and I'm still not sure exactly what the contents of such a file should
look like.
Any good ideas on implementing this? If we don't reach any good
conclusion right away I'll probably start with just one generic dir
and no staging, which is the simplest and just requires one new -I.
Then we can extend later as needed.
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.
