Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.