Re: Support for out-of-tree build

[Petr Hosek <phosek@chromium.org>]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

How would you express the fact that e.g. armhf subarch should use armel
implementation of memcpy.s?

On Tue, Nov 17, 2015 at 1:00 PM Rich Felker <dalias@libc.org> wrote:

> On Tue, Nov 17, 2015 at 02:45:58AM +0000, Petr Hosek wrote:
> > This is the final solution I've converged to. It's a bigger change than
> the
> > previous version, but the implementation is actually cleaner. In
> nutshell,
> > I've replaced all .sub files with .mk equivalent files which are included
> > from the Makefile. I'm then filtering out all C object files which have
> > assembly equivalent. This allowed me to simplify the build rules while we
> > still support both in-tree and out-of-tree builds. Please let me know
> what
> > you think, I'll be happy to iterate on this.
>
> What I had in mind was something more like a single fragment for the
> arch containing something like (example on sh with 3 subarch
> dimensions, where full arch with subarch is sheb-nofpu-fdpic):
>
> %.o: sheb/%.s
>         $(AS_CMD)
>
> %.o: sh-nofpu/%.s
>         $(AS_CMD)
>
> %.o: sh-fdpic/%.s
>         $(AS_CMD)
>
> Even better would be just an ordered list of subarch subdirs that the
> top-level makefile can interpret:
>
> SUBARCH_ASM_DIRS = sheb sh-nofpu sh-fdpic
>
> Replacing *.sub with *.mk is not an improvement from my perspective;
> rather, it's replacing N files which just contained one piece of data
> (a filename) with N files each coupled with the makefile logic.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 1853 bytes --]