From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8881 Path: news.gmane.org!not-for-mail From: Petr Hosek Newsgroups: gmane.linux.lib.musl.general Subject: Re: Support for out-of-tree build Date: Tue, 17 Nov 2015 21:37:37 +0000 Message-ID: References: <20151111230848.GZ3818@brightrain.aerifal.cx> <20151112145026.GB18372@port70.net> <20151112203048.GB3818@brightrain.aerifal.cx> <20151112211024.GC18372@port70.net> <20151112215232.GC3818@brightrain.aerifal.cx> <20151112234137.GD3818@brightrain.aerifal.cx> <20151117210021.GB3818@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114844ec330b770524c35688 X-Trace: ger.gmane.org 1447796301 28526 80.91.229.3 (17 Nov 2015 21:38:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 21:38:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8894-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 17 22:38:11 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 1Zynwx-0005ay-Sp for gllmg-musl@m.gmane.org; Tue, 17 Nov 2015 22:38:04 +0100 Original-Received: (qmail 8105 invoked by uid 550); 17 Nov 2015 21:38:00 -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 8086 invoked from network); 17 Nov 2015 21:37:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=ppIr2YAwAyJoGWH4f4oX1I0XFQCir9Qe9F+uPdipXk4=; b=XvxkciwQZ8Ldv7o/ThYN9Yzp2xo13OUMwZPASJgFtDAeobImRYMxy6CKrA5x2T5tXT DcrVkBH1vafypHmLCi+Aq6YbgqiOVA/1L2wpa1txOeQZe9ihoKZq7vAPCKAqCebHKjEK VClZ3FLU62FFobFFkwBNk1p645EsT/8iJ7woQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=ppIr2YAwAyJoGWH4f4oX1I0XFQCir9Qe9F+uPdipXk4=; b=g9nzB5jcWAKK1uMs5g7XVjD6W3fR8CRokh3N8tSWTeBaJuxyU2u4SSjqprrvXaFcxL RU9h7itJnO8AZmJdGw+IiglUqxE7QiWzELeCGUrhUJo4Y9ZEnD33axkAExrRYWDfVQdi Nml00COcDED3trk5R3Oyq9+XWb66d6mkEMeN8r6MduIFn/75wqaaI7QXkW8rGqrvvC2C 6QzkpfyteqxgDYH3nrm+Tg9N+taKejkHIJpTpRIsB6s8nuRpkBxwOT+UmF9uMPMyUtWO a5yRnUn1/PT4sKWUB3ZdQHj4Jj4dp8ibWbjqJnzZ20o7qWn8QuXTB6FtsSfV1iM9WT4o jBVQ== X-Gm-Message-State: ALoCoQl93owhftcXAOLQ5+ATkWGpSeHE3hvg7HVZ1q+K138Chc3ESRdlPi7vn2UHOZ8xZMFzDRca X-Received: by 10.129.101.134 with SMTP id z128mr42642658ywb.92.1447796266932; Tue, 17 Nov 2015 13:37:46 -0800 (PST) In-Reply-To: <20151117210021.GB3818@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8881 Archived-At: --001a114844ec330b770524c35688 Content-Type: text/plain; charset=UTF-8 How would you express the fact that e.g. armhf subarch should use armel implementation of memcpy.s? On Tue, Nov 17, 2015 at 1:00 PM Rich Felker wrote: > On Tue, Nov 17, 2015 at 02:45:58AM +0000, Petr Hosek wrote: > > This is the final solution I've converged to. It's a bigger change than > the > > previous version, but the implementation is actually cleaner. In > nutshell, > > I've replaced all .sub files with .mk equivalent files which are included > > from the Makefile. I'm then filtering out all C object files which have > > assembly equivalent. This allowed me to simplify the build rules while we > > still support both in-tree and out-of-tree builds. Please let me know > what > > you think, I'll be happy to iterate on this. > > What I had in mind was something more like a single fragment for the > arch containing something like (example on sh with 3 subarch > dimensions, where full arch with subarch is sheb-nofpu-fdpic): > > %.o: sheb/%.s > $(AS_CMD) > > %.o: sh-nofpu/%.s > $(AS_CMD) > > %.o: sh-fdpic/%.s > $(AS_CMD) > > Even better would be just an ordered list of subarch subdirs that the > top-level makefile can interpret: > > SUBARCH_ASM_DIRS = sheb sh-nofpu sh-fdpic > > Replacing *.sub with *.mk is not an improvement from my perspective; > rather, it's replacing N files which just contained one piece of data > (a filename) with N files each coupled with the makefile logic. > > Rich > --001a114844ec330b770524c35688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How would you express the fact that e.g. armhf subarch sho= uld use armel implementation of memcpy.s?

On Tue, Nov 17, 2015 at 1:00 PM Rich Felker <dalias@libc.org> wrote:
On Tue, Nov 17, 2015 at 02:45:58AM +0000, Petr Hose= k wrote:
> This is the final solution I've converged to. It's a bigger ch= ange than the
> previous version, but the implementation is actually cleaner. In nutsh= ell,
> I've replaced all .sub files with .mk equivalent files which are i= ncluded
> from the Makefile. I'm then filtering out all C object files which= have
> assembly equivalent. This allowed me to simplify the build rules while= we
> still support both in-tree and out-of-tree builds. Please let me know = what
> you think, I'll be happy to iterate on this.

What I had in mind was something more like a single fragment for the
arch containing something like (example on sh with 3 subarch
dimensions, where full arch with subarch is sheb-nofpu-fdpic):

%.o: sheb/%.s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 $(AS_CMD)

%.o: sh-nofpu/%.s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 $(AS_CMD)

%.o: sh-fdpic/%.s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 $(AS_CMD)

Even better would be just an ordered list of subarch subdirs that the
top-level makefile can interpret:

SUBARCH_ASM_DIRS =3D sheb sh-nofpu sh-fdpic

Replacing *.sub with *.mk is not an improvement from my perspective;
rather, it's replacing N files which just contained one piece of data (a filename) with N files each coupled with the makefile logic.

Rich
--001a114844ec330b770524c35688--