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.