[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABBv4TYxZ35H-zKFDn826W3Gh0vZC2iEuY6_DHvRMOD=H7DYDw@mail.gmail.com>
Date: Tue, 17 Nov 2015 21:37:37 +0000
From: Petr Hosek <phosek@...omium.org>
To: musl@...ts.openwall.com
Subject: Re: Support for out-of-tree build
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@...c.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
>
Content of type "text/html" skipped
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.
