ideas for build system changes, bits refactoring

[Rich Felker <dalias@libc.org>]

I'd like to start a list of ideas and discussion for changes we could
make to the build system and arch bits. This has been on the agenda a
long time but it's going to be more important as we get more ports,
both as a way of managing complexity and as a way of fighting source
tree bloat. Here are some ideas I have so far:

1. Generate all installable include files, even if just by copying, as
part of the build. If nothing else, this will ensure that "make clean"
followed by "make install" overwrites any (non-future-dated)
preexisting files at the install destination; right now, that might
fail to happen if changes were made at the install destination and the
source timestamp is older. I think this will also make it easier to
add out-of-tree build since there won't need to be separate logic for
generated headers in-tree vs out-of-tree. It will also give us the
option (not sure if we should take it) to merge bits into the main
headers rather than having a bits dir under include.

2. Factor arch bits (types, struct layouts, constant values, etc.) as
a sequence of overlays: a generic base, several common families like
32-bit, 64-bit, 64-bit+ILP32, ld-64, ld-80, ld-128, and finally
arch-specific bits. The latter should be nearly empty for most archs.

3. Moving arch-specific build logic out of the configure script and
into a makefile fragment in the arch dir. This should support the
long-term goal of reducing/eliminating the work configure does and
moving it to declarative rules in make. It also isolates
port-specific logic with the port rather than hard-coding it in a
shared script.

4. Eliminate the duplication of SYS_* and __NR_* in syscall.h bits by
auto-generating one from the other as part of the build process.


Rich