From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2357 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Design idea for subarchs/abivariants Date: Wed, 28 Nov 2012 18:57:45 -0500 Message-ID: <20121128235745.GT20323@brightrain.aerifal.cx> References: <20121128192618.GA7491@brightrain.aerifal.cx> <20121128120341.ca114e90.idunham@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1354147085 15159 80.91.229.3 (28 Nov 2012 23:58:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2012 23:58:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2358-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 29 00:58:16 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TdrW4-0000e4-MI for gllmg-musl@plane.gmane.org; Thu, 29 Nov 2012 00:58:08 +0100 Original-Received: (qmail 31753 invoked by uid 550); 28 Nov 2012 23:57:57 -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 30717 invoked from network); 28 Nov 2012 23:57:56 -0000 Content-Disposition: inline In-Reply-To: <20121128120341.ca114e90.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2357 Archived-At: On Wed, Nov 28, 2012 at 12:03:41PM -0800, Isaac Dunham wrote: > On Wed, 28 Nov 2012 14:26:18 -0500 > Rich Felker 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. > > > 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, */.s is going to get every > appropriate file. I don't have a lot of preference one way or the other. I'd probably use $(ARCH)/$(ARCH)$(SUBARCH) though, since $(SUBARCH) is likely to be an awkward string like "-sf" that's ugly and error-prone as a directory name (easily misinterpreted as an option). > By the way, while we're on the makefile: > in the past, I've run into issues with cycles like: > make > > git pull # or git checkout .... > make clean # doesn't handle files that were moved/deleted > make # link breaks, due to remaining oject files This is not possible. Spurious *.o files lying around do not get used whatsoever in the build process, for the exact same reason that they do not yet deleted by "make clean". > I usually do this to cleanup in such cases: > find src arch -name '*.*o' |xargs rm There are no .o files under arch. It's purely headers. > Would adding some similar logic be sensible (at least for the > distclean target)? I'm a little bit hesitant to delete files that we didn't create. This could lead to deleting a file that somebody did not want deleted, which I really don't want to be responsible for.. Rich