This'll work if we remove the .sub files as discussed, with .sub files it becomes more complicated. On Tue, Nov 17, 2015 at 3:43 PM Rich Felker wrote: > On Tue, Nov 17, 2015 at 06:27:11PM -0500, Rich Felker wrote: > > 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. > > Here's my idea for the 'tricky' setting of OBJS and it actually looks > very simple and efficient: > > ARCH_OBJS = $(wildcard ...) > BASE_OBJS = $(wildcard ...) > OBJS = $(ARCH_OBJS) $(filter-out $(ARCH_OBJS:/$(ARCH)/=/),$(BASE_OBJS)) > > If the above all works I think we have a pretty good path forward. > > It does change where the .o files for arch-specific sources live (one > level deeper in the tree) and requires these dirs to be created in the > output tree, but I think this is actually an improvement since > removing an arch source file will result in the base-level .o file > being built (right now the stale .o file based on the arch asm sticks > around). > > Presumably we can also just do: > > LOBJS = $(OBJS:.o=.lo) > > although it's my intent to remove LOBJS soon anyway and instead have > pic/non-pic objs (and only use pic ones by default). How to name them > will be a fun bikeshed... > > Rich >