From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8820 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Support for out-of-tree build Date: Sat, 7 Nov 2015 19:43:23 -0500 Message-ID: <20151108004323.GE3818@brightrain.aerifal.cx> References: <20151107130537.GC8500@port70.net> 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 1446943420 18306 80.91.229.3 (8 Nov 2015 00:43:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 00:43:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8833-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 08 01:43:40 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 1ZvE55-0002WG-4d for gllmg-musl@m.gmane.org; Sun, 08 Nov 2015 01:43:39 +0100 Original-Received: (qmail 1334 invoked by uid 550); 8 Nov 2015 00:43:37 -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 32746 invoked from network); 8 Nov 2015 00:43:36 -0000 Content-Disposition: inline In-Reply-To: <20151107130537.GC8500@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8820 Archived-At: On Sat, Nov 07, 2015 at 02:05:37PM +0100, Szabolcs Nagy wrote: > * Petr Hosek [2015-11-06 23:40:48 +0000]: > > I'm porting musl to (Portable) Native Client. One of the requirements we > > have is out-tree-build; I've found an older patch from Szabolcs Nagy so > > yes, this is on the roadmap for a while now > there were various iterations of this Great to see more interest in this right when I wanted to make it happen. :) > one limitation of the VPATH approach is that > mixing in-tree and out-tree builds breaks: > if build targets are found in the source dir > after a previous in-tree build then those are > not rebuilt out-tree. > > so at least there should be some check in the > Makefile (e.g. if config.mak exists in-tree > during an out-tree build) Yes, I think this could be reliably detected. I would not even be opposed to getting rid of "true in-tree" builds, i.e. always putting output in a subdirectory of the top-level musl dir if the build is configured for in-tree, if that's practical. Thoughts? > the other approach is to change the problematic > > %.o: $(ARCH)/%.s > > rules, because > > /%.o: $(srcdir)//$(ARCH)/%.s > > cannot be expressed in make. > (e.g. the dirs under src/ could be explicitly > listed and then just adding $(srcdir)/ to all > rules would make it work and in-/out-tree could > be mixed.) I would very strongly prefer to avoid anything that involves adding additional rules beyond O(1). Rule-per-file or rule-per-dir is undesirable. There are ways it could be avoided at the actual makefile level by using fancy GNU make features for expanding at make time, but this generally yields very bad performance (see the current *.sub stuff we have, which I want to remove, and which was a major performance hit when it was added) and reduces ease of human comprehension of the makefile. > > +ifneq ($(srcdir),.) > > +VPATH = $(srcdir) > > +$(ALL_TOOLS): tools/.dirstamp > > +$(ALL_LIBS): lib/.dirstamp > > +$(CRT_LIBS:lib/%=crt/%): crt/.dirstamp > > +$(OBJS) $(LOBJS): $(patsubst %/,%/.dirstamp,$(sort $(dir $(OBJS)))) > > +$(GENH): arch/$(ARCH)/bits/.dirstamp > > +include/bits: include/.dirstamp > > +src/internal/version.h: src/internal/.dirstamp > > +%/.dirstamp: > > + mkdir -p $* > > + touch $@ > > +endif > > + > > i guess this works without the ifneq, just > litters the source dir with .dirstamps in > case of an in-tree build. What is the motive for having these .dirstamps at all? > > +.SECONDARY: > > > > what does .SECONDARY do? It's buggy and can't be used. See commit d18cf76d73df8f9cc751d4b4ba5a635c70c0c645. > > diff --git a/configure b/configure > > index dece1d0..b2d0c8d 100755 > > --- a/configure > > +++ b/configure > > @@ -9,6 +9,9 @@ VAR=VALUE. See below for descriptions of some of the useful variables. > > > > Defaults for the options are specified in brackets. > > > > +Configuration: > > + --srcdir=DIR source directory [detected] > > + Does this match standard configure behavior? > > +# Get the musl source dir for out-of-tree builds > > +# > > +if test -z "$srcdir" ; then > > +srcdir="${0%/configure}" > > +stripdir srcdir > > +fi > > +abs_builddir="$(pwd)" || fail "$0: cannot determine working directory" > > +abs_srcdir="$(cd $srcdir && pwd)" || fail "$0: invalid source directory $srcdir" > > +test "$abs_srcdir" = "$abs_builddir" && srcdir=. > > +ln -sf $srcdir/Makefile . Is it possible to get a relative path for the srcdir rather than an absolute one here? I really don't like configurations that are not relocatable in the filesystem. > > # Get a temp filename we can use > > # > > i=0 > > @@ -293,6 +310,7 @@ microblaze*) ARCH=microblaze ;; > > or1k*) ARCH=or1k ;; > > powerpc*) ARCH=powerpc ;; > > sh[1-9bel-]*|sh|superh*) ARCH=sh ;; > > +le32*) ARCH=le32 ;; > > is le32 something native client related? I'm pretty sure it is. Rich