From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7193 Path: news.gmane.org!not-for-mail From: Bobby Bingham Newsgroups: gmane.linux.lib.musl.general Subject: Re: ideas for build system changes, bits refactoring Date: Sun, 15 Mar 2015 18:47:56 -0500 Message-ID: <20150315234755.GA27261@duality.lan> References: <20150312035954.GA31639@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" X-Trace: ger.gmane.org 1426464076 4585 80.91.229.3 (16 Mar 2015 00:01:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Mar 2015 00:01:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7206-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 16 01:01:16 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YXIT5-0005tb-I9 for gllmg-musl@m.gmane.org; Mon, 16 Mar 2015 01:01:15 +0100 Original-Received: (qmail 5153 invoked by uid 550); 16 Mar 2015 00:01:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5126 invoked from network); 16 Mar 2015 00:01:13 -0000 Content-Disposition: inline In-Reply-To: <20150312035954.GA31639@brightrain.aerifal.cx> X-Operating-System: Linux duality 3.13.5-gentoo User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:7193 Archived-At: --T4sUOijqQbZv57TR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVBhorAAoJEFedFv6RmqC9+YQP/3ndStOK69TBvi9NU0azXS0F Rn3GFhgJkh4AYR7p9y9WXBSb+Khs33l8kvtG96IxwIF6YOa+xcDuRDnRK0QlB0kx 4sop/hgDMj/Gcir1BkAtGrLAXTDmOj+dbqlOIgyqZKkV39xMMlwDETzJrCpOQwCM 5eAqv2G3+Hit3WPFzbJlOsj9ClWcZCI+HhEODKEtn2EKjoPKzoGX0qd047exTtb6 hB+37MDcEvhKfH1OZdGB0qAzMLNuq6J45OdFxladeST7SsbvfyjzM3QJwgi249m7 M1aeafZQ6yzdG5YsScObgj+iKmE5kb0AeQIR1E2+0DOAsp+oCbklOsHyQ0ToKRHs bf4iN5pqlql2Vnfz8KBaO511La3O7a4ARrNSsiQtU+4bI8PiSYeMA65VxXW9Eu9O +RDqfhTi+nWNyKB5RuNmRyLv1Ll6E8ZuYFIiBa69l7ZYd+TpECciz5QMk8COxSiA JZVguQ7dD/+QEAAWRS1XmAf1Xc6tcuJ9vYZy0M1tVU326L8Mn73PkAUbK+lpW0VE DzVh/+FbPBxM4lm4Hz9CgoG+/YdZzfXc9W3rp54LX/e6ZS+OES0u3oOjddbZwPlF Twn/ZqT2uydUTAwdfIVcyIYvdXNJnzjS3akR9wXwjhpkdKJxZBA0J0pUR+d86U4o dVnMh4GAsuI1r82Bt2YQ =3lV9 -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR--