Christian Weisgerber <naddy@mips.inka.de> wrote:> | # nasm build rule: > | %.lo: %.sEven with gmake, this really works only by accident. Automake generates a competing suffix rule, and gmake apparently gives the rule above a higher priority than the suffix rule (or that just happens to be the evaluation order). Matt, since you seem to understand automake, can you come up with something to properly integrate this with automake's logic?> .SUFFIXES: .lo .s > .s.lo:(This of course doesn't work with automake.) -- Christian "naddy" Weisgerber naddy@mips.inka.de
Josh Coalson <xflac@yahoo.com> wrote:> it doesn't look like there's a provision for compiling .s files > with a different program than .c files, or even different flags. > so now I have no idea how to make this work as we would like.What again was our rationale for switching from .nasm to .s? <checks archive> Oh, I see, the automake/libtool magic for creating a library doesn't work otherwise. Maybe that wasn't the right path. -- Christian "naddy" Weisgerber naddy@mips.inka.de
Matt Zimmerman <mdz@debian.org> wrote:> > > .SUFFIXES: .lo .s > > > .s.lo: > > > > (This of course doesn't work with automake.) > > It doesn't? Anything in a Makefile.am that doesn't appear to be special > automake magic is passed through to the Makefile (via Makefile.in).Yes, but... Hey, you're right. I thought I had seen automake insert its own .s.lo rule anyway, with both rules ending up in the result, but apparently I've been mistaken. Sorry for the confusion. :-( Indeed, this works: --- src/libFLAC/i386/Makefile.am.orig Sat Jun 9 21:48:49 2001 +++ src/libFLAC/i386/Makefile.am Sat Jun 9 21:49:05 2001 @@ -1,5 +1,6 @@ # nasm build rule: -%.lo: %.s +SUFFIXES = .s .lo +.s.lo: $(NASM) -f elf -d ELF $< -o $@ noinst_LTLIBRARIES = libFLAC-asm.la -- Christian "naddy" Weisgerber naddy@mips.inka.de
Josh Coalson <xflac@yahoo.com> wrote:> .s.lo: > $(LIBTOOL) --mode=compile $(COMPILE) -c $< > > it doesn't look like there's a provision for compiling .s files > with a different program than .c files, or even different flags.Explicit rules override suffix rules. It's not elegant, but we could just write down the individual rules: --- src/libFLAC/i386/Makefile.am.orig Thu Jun 7 20:39:34 2001 +++ src/libFLAC/i386/Makefile.am Thu Jun 7 20:40:18 2001 @@ -1,7 +1,13 @@ # nasm build rule: -%.lo: %.s - $(NASM) -f elf -d ELF $< -o $@ +cpu_asm.lo: cpu_asm.s + $(NASM) -f elf -d ELF $? -o $@ +fixed_asm.lo: fixed_asm.s + $(NASM) -f elf -d ELF $? -o $@ + +lpc_asm.lo: lpc_asm.s + $(NASM) -f elf -d ELF $? -o $@ + noinst_LTLIBRARIES = libFLAC-asm.la libFLAC_asm_la_SOURCES = \ cpu_asm.s \ -- Christian "naddy" Weisgerber naddy@mips.inka.de
> > | # nasm build rule: > > | %.lo: %.s > > Even with gmake, this really works only by accident. Automake > generates a competing suffix rule, and gmake apparently gives the > rule above a higher priority than the suffix rule (or that just > happens to be the evaluation order). >but when I do automake the competing build rule is nestled with others and looks like: .c.lo: $(LIBTOOL) --mode=compile $(COMPILE) -c $< .s.lo: $(LIBTOOL) --mode=compile $(COMPILE) -c $< .S.lo: $(LIBTOOL) --mode=compile $(COMPILE) -c $< it doesn't look like there's a provision for compiling .s files with a different program than .c files, or even different flags. so now I have no idea how to make this work as we would like. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
On Sat, Jun 02, 2001 at 01:17:48AM +0000, Christian Weisgerber wrote:> Christian Weisgerber <naddy@mips.inka.de> wrote: > > > | # nasm build rule: > > | %.lo: %.s > > Even with gmake, this really works only by accident. Automake > generates a competing suffix rule, and gmake apparently gives the > rule above a higher priority than the suffix rule (or that just > happens to be the evaluation order).As far as I know, this is the correct way to override a default pattern/suffix rule. The one specified explicitly should override the default.> Matt, since you seem to understand automake, can you come up with > something to properly integrate this with automake's logic?I believe this can be fixed by adding .s to automake's SUFFIXES variable (not to be confused with .SUFFIXES). I need to look into it a bit more.> > .SUFFIXES: .lo .s > > .s.lo: > > (This of course doesn't work with automake.)It doesn't? Anything in a Makefile.am that doesn't appear to be special automake magic is passed through to the Makefile (via Makefile.in). How is it failing? -- - mdz