From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8888 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 23:54:23 +0000 Message-ID: References: <20151112211024.GC18372@port70.net> <20151112215232.GC3818@brightrain.aerifal.cx> <20151112234137.GD3818@brightrain.aerifal.cx> <20151117210021.GB3818@brightrain.aerifal.cx> <20151117220141.GD3818@brightrain.aerifal.cx> <20151117230606.GJ18372@port70.net> <20151117232711.GG3818@brightrain.aerifal.cx> <20151117234330.GH3818@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c07eaa059825c0524c53f83 X-Trace: ger.gmane.org 1447804488 26082 80.91.229.3 (17 Nov 2015 23:54:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 23:54:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8901-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 18 00:54:48 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 1Zyq5H-0003mf-UO for gllmg-musl@m.gmane.org; Wed, 18 Nov 2015 00:54:48 +0100 Original-Received: (qmail 3313 invoked by uid 550); 17 Nov 2015 23:54:46 -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 3280 invoked from network); 17 Nov 2015 23:54:45 -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=5FJLlCg+QMWY5tx7OXWvMThznyHssttJpi6bKDMCPdM=; b=dVU/yx2KGsnjKiwNwvvFBFNJs6ZdKptGCJc7++SUSvzzOMA+DE79qmqinuKKF+Gq2y qCRYlRpPg3el0BzH/EcikJM76xoXtPPF1EtdF+axzBv6fdZ0oTlINLQwRWl9lbe5Md/p NdbOxP2rTEdumUT20ijN3UNS+hS6UAzypQoJ0= 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=5FJLlCg+QMWY5tx7OXWvMThznyHssttJpi6bKDMCPdM=; b=J+FUmPCKLIjsaPB1qRIZ2SR9mG8fYBQgo1h/vNufcV9K3CD/vH85YG7MPc3t/DTQnb 6eWXMsoqphGRNoNKHDQCBjQHk52EDl6LS0ymsEfVNT1A994wHg+ukdtEPuwZygpQbIQ0 OdXQ++DUSM5i/rupjAh63LgGjhAe0jY7X1FPfTWkxgP0bjeroTyCtlPrwNvlPobaLPx2 vChEA05t/BhVGu1BZXcZ5HtlmYhWJgPz56cYxvxpk9A/sDIw8XYSKJHo4WmLVCHna/ys X3JyQD4UzKx6FG+0vmwyeG7AtYtmHT8G53E+0+rpX75erpSekcKeescY3tuMwEcAblJ4 9UKg== X-Gm-Message-State: ALoCoQljNMI7mcF710c3iL9SvPGJdftXvWy2GddAnhIbCZC+JjtV1qhV2MmYet9qRnuSE5/INLII X-Received: by 10.13.218.68 with SMTP id c65mr41471676ywe.315.1447804473524; Tue, 17 Nov 2015 15:54:33 -0800 (PST) In-Reply-To: <20151117234330.GH3818@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8888 Archived-At: --94eb2c07eaa059825c0524c53f83 Content-Type: text/plain; charset=UTF-8 This'll work if we remove the .sub files as discussed, with .sub files it becomes more complicated. On Tue, Nov 17, 2015 at 3:43 PM Rich Felker wrote: > On Tue, Nov 17, 2015 at 06:27:11PM -0500, Rich Felker wrote: > > Assuming .o files in arch dirs are ok, does the following work > > (non-VPATH)? > > > > %.o: $(srcdir)/%.sub > > ... > > %.o: $(srcdir)/%.s > > ... > > %.o: $(srcdir)/%.c > > ... > > > > (with appropriate commands, of course). If so, I think I like it a > > lot, because it factors the rules for file *types* separately from the > > rules for which files to select (the "tricky" $(OBJS) setting). The > > only big concern is whether this "tricky" setting is too costly in > > runtime performance or complexity. > > Here's my idea for the 'tricky' setting of OBJS and it actually looks > very simple and efficient: > > ARCH_OBJS = $(wildcard ...) > BASE_OBJS = $(wildcard ...) > OBJS = $(ARCH_OBJS) $(filter-out $(ARCH_OBJS:/$(ARCH)/=/),$(BASE_OBJS)) > > If the above all works I think we have a pretty good path forward. > > It does change where the .o files for arch-specific sources live (one > level deeper in the tree) and requires these dirs to be created in the > output tree, but I think this is actually an improvement since > removing an arch source file will result in the base-level .o file > being built (right now the stale .o file based on the arch asm sticks > around). > > Presumably we can also just do: > > LOBJS = $(OBJS:.o=.lo) > > although it's my intent to remove LOBJS soon anyway and instead have > pic/non-pic objs (and only use pic ones by default). How to name them > will be a fun bikeshed... > > Rich > --94eb2c07eaa059825c0524c53f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This'll work if we remove the .sub files as discussed,= with .sub files it becomes more complicated.

On Tue, Nov 17, 2015 at 3:43 PM Rich Felker <dalias@libc.org> wrote:
On Tue, Nov 17, 2015 at 06:27:11PM -0500, Rich = Felker wrote:
> Assuming .o files in arch dirs are ok, does the following work
> (non-VPATH)?
>
> %.o: $(srcdir)/%.sub
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
> %.o: $(srcdir)/%.s
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
> %.o: $(srcdir)/%.c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
> (with appropriate commands, of course). If so, I think I like it a
> lot, because it factors the rules for file *types* separately from the=
> rules for which files to select (the "tricky" $(OBJS) settin= g). The
> only big concern is whether this "tricky" setting is too cos= tly in
> runtime performance or complexity.

Here's my idea for the 'tricky' setting of OBJS and it actually= looks
very simple and efficient:

ARCH_OBJS =3D $(wildcard ...)
BASE_OBJS =3D $(wildcard ...)
OBJS =3D $(ARCH_OBJS) $(filter-out $(ARCH_OBJS:/$(ARCH)/=3D/),$(BASE_OBJS))=

If the above all works I think we have a pretty good path forward.

It does change where the .o files for arch-specific sources live (one
level deeper in the tree) and requires these dirs to be created in the
output tree, but I think this is actually an improvement since
removing an arch source file will result in the base-level .o file
being built (right now the stale .o file based on the arch asm sticks
around).

Presumably we can also just do:

LOBJS =3D $(OBJS:.o=3D.lo)

although it's my intent to remove LOBJS soon anyway and instead have pic/non-pic objs (and only use pic ones by default). How to name them
will be a fun bikeshed...

Rich
--94eb2c07eaa059825c0524c53f83--