[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150304235346.GH16260@port70.net>
Date: Thu, 5 Mar 2015 00:53:46 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Patch to allow configure out-with source directory
* Rich Felker <dalias@...c.org> [2015-03-04 12:45:55 -0500]:
> On Wed, Mar 04, 2015 at 05:52:30PM +0100, Laurent Bercot wrote:
> > to study a small and clean case - and was considering implementing
> > out-of-tree builds at some point in the (distant) future. If there
> > were some notes describing the obstacles you faced, it would help
> > me when I get to it - or more likely convince me, like it
> > apparently convinced you, that it's just not worth it.
>
> The first problem you face is how the implicit rules are written,
> especially the ones for asm files that replace C files. They depend on
> make's implicit application of leading directories. But I'm pretty
> sure nsz had this worked out clearly and it was more subtle corner
> cases that kept biting. He could probably explain better.
>
i couldnt fix the implicit rules issue
http://www.openwall.com/lists/musl/2014/02/06/6
i worked it around with vpath:
http://www.openwall.com/lists/musl/2014/02/08/1
> Another issue I recall is the presence of generated include files and
> the bits symlink in the include tree. This is part of the build
> process I want to revisit/change anyway when refactoring the bits
> headers to reduce duplication, so understanding the obstacles to
> out-of-tree builds before getting started with that would be a big
> help.
the vpath solution cannot work in all cases:
it magically adds the srcdir prefix to the right side
of make rules (if otherwise the file is not found)
but if a right side is generated and you have an in-tree
build then the out-of-tree build will find the generated
file in-tree and use that instead of rebuilding it
(of course this only matters if one mixes in-tree and
out-of-tree builds, which is not a good idea in general
so we could warn instead of fixing it)
if you could apply vpath selectively only to non-generated
source files that would fix the issue, but i havent found
any way to do that
normally explicit $(srcdir) prefixing would be the clean
solution but the current implicit rules in musl don't work
with that:
%.o: $(ARCH)/%.s
can expand to "src/foo/bar.o: src/foo/i386/bar.s", but
%.o: $(srcdir)/???/$(ARCH)/%.s
does not work
other approaches are possible: eg. generate the .o rules
with foreach, generate the entire Makefile, etc
i havent tried these
i attach the vpath version that mostly works
View attachment "out-of-tree.diff" of type "text/x-diff" (6470 bytes)
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.
