Re: Support for out-of-tree build

[Rich Felker <dalias@libc.org>]

On Wed, Nov 18, 2015 at 12:06:08AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-11-17 17:01:41 -0500]:
> > However, at this point I'm strongly considering whether we should just
> > do away with the subarch dirs entirely and use preprocessed asm or C
> > with inline asm in their place. The one place this is mildly difficult
> ....
> > 
> > Would this make things simpler for the build system? I think so.
> 
> ok, but that's a separate change then

Yes, but rather than introduce a lot of mess and complexity in the
build system then go trying to remove it, I'd rather first think
through what simple related changes could be made that would eliminate
the need to add that mess in the first place. This yields a cleaner,
easier-to-understand history and ensures that the prerequisite changes
actually happen first so we don't end up stuck with a mess because the
changes to make it go away get put off. :)

> i think the relevant decision for out-of-tree is
> if we want to keep
> 
> %.o: $(ARCH)/%.s
> 
> which means VPATH is needed, or if it's ok to have
> ..o files under the $(ARCH) dir, so the rules are just
> 
> %.o: %.s
> 
> %.o: %.sub
> 
> (of course setting $(OBJS) is more tricky then)

Assuming .o files in arch dirs are ok, does the following work
(non-VPATH)?

%.o: $(srcdir)/%.sub
	...
%.o: $(srcdir)/%.s
	...
%.o: $(srcdir)/%.c
	...

(with appropriate commands, of course). If so, I think I like it a
lot, because it factors the rules for file *types* separately from the
rules for which files to select (the "tricky" $(OBJS) setting). The
only big concern is whether this "tricky" setting is too costly in
runtime performance or complexity.

> i think we can then do out-of-tree independently from
> the subarch changes.

I don't see a good way to do this without introducing a fairly large
amount of mess we plan to immediately remove, unless we just go the
VPATH route and leave most of the *.sub stuff alone.

Rich