Date: Sun, 15 Mar 2015 18:47:56 -0500 From: Bobby Bingham <koorogi@...rogi.info> To: musl@...ts.openwall.com Subject: Re: ideas for build system changes, bits refactoring On Wed, Mar 11, 2015 at 11:59:54PM -0400, Rich Felker wrote: > 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. Do you mean that a final bits header would come from one of these overlays that hadn't been overridden by another overlay, or would be a composite built from pieces provided by the different overlays? For example, powerpc/bits/errno.h is nearly identical to the file used on most other architectures, just with a different value of EDEADLOCK. Would the powerpc arch-specific errno.h need to redefine all of the values, or would it be able to inherit most of the values from the generic base and just override EDEADLOCK? > > 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. > 5. This may be orthogonal to the rest of these ideas, but what about providing thin wrappers for the syscalls used by musl itself, similar to the __sys_open* macros already provided by internal/syscall.h? I think it would help for bare metal targets to be able to implement one individual function per syscall, rather than needing to implement a whole syscall dispatcher. > > Rich -- Bobby Bingham Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
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.