Re: Support for out-of-tree build

[Rich Felker <dalias@libc.org>]

On Thu, Nov 12, 2015 at 10:10:24PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-11-12 15:30:48 -0500]:
> > On Thu, Nov 12, 2015 at 08:17:05PM +0000, Petr Hosek wrote:
> > > There is one other issue with the VPATH solution which I just realized
> > > while trying to make changes to the original patch: the order-only
> > > dependencies don't work with VPATH because the directories already exist
> > > the source directory, so we'd need to use the solution with .dirstamps.
> > 
> > Alternatively, configure could be responsible for making the skeleton
> > tree at the same time it puts a Makefile in the build dir. I don't
> > know if I like this approach but it's achievable with a simple find
> > command.
> > 
> 
> that only works if no new source directories are added after configure.

Yes. For active development where you don't want to re-run configure
all the time that could be a pain. I was thinking more just for
automated builds.

> > I'm still uncertain which approach (VPATH or non-VPATH) we should
> > take, so I'm trying to reason through the consequences of both.
> > 
> 
> depends on if we change the src/dir/arch layout and sub handling.
> 
> if we dont change anything then i think vpath with dirstamps is
> the cleanest solution.

I don't like it a lot, but it's not horrible, and it does solve the
problem with supporting new dirs.

> it might be worth looking at how well make handles generated rules
> with foreach (instead of %.o patterns), then we can use whatever
> directory layout and precedence rules.

I think this is very slow. The stuff I added for .sub files was a big
performance regression.

What if we put the *.o files for arch asm in the arch dirs rather than
in the main src dirs. Is there some clean way we could write a rule to
remove the base .o files from OBJS when the arch-specific .o files are
there?

Rich