[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Nov 2015 19:43:23 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Support for out-of-tree build
On Sat, Nov 07, 2015 at 02:05:37PM +0100, Szabolcs Nagy wrote:
> * Petr Hosek <phosek@...omium.org> [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
>
> <dir>/%.o: $(srcdir)/<dir>/$(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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
