Bruce,
Thanks for the response, and sorry about my spam filter at UDel - I
haven't figured out a way to auto-whitelist responses to my outgoing
list email (or even plain outgoing email - I'm not that much of a
procmail hacker yet).
So LDADD as opposed to LIBADD?
And I gather I should say:
libfoo_common = a.c b.c c.c ...
libfoo_SOURCES = bar.c $(libfoo_common)
libfoosim_SOURCES = bar_s.c ($libfoo_common)
bar_s_o_CFLAGS = $(CFLAGS) -DSIM # Not sure about this line...
bar$U.$(OBJEXT): bar$U.c bar_s$U.$(OBJEXT)
$(COMPILE) ...
bar_s$U.$(OBJEXT): bar$U.c
COMPILE handling the bar_s_o_CFLAGS
(I'm not using libtool - this app does not do shared libraries.)
Harlan
--
> Harlan Stenn wrote:
>
> > I now have to build two libraries, libfoo.a and libfoosim.a, where the
> > only difference between the two libraries is that bar.c is compiled
> > "normally" for libfoo.a, but for libfoosim.a I need to also supply
> > -DSIM when compiling bar.c .
> >
> > As you might imagine, I'm doing this in an environment that must support
> > de-ANSI-fication.
> >
> > Ideas?
>
> Use specific rules for building bar.c producing differently named
> .o files. LDADD the proper object for the proper library.
> Reverse engineer the Makefile.in to discover the rules to use.
> Something along the lines of:
>
> $(LTCOMPILE) -DSIM -c -o barsim.lo \
> `test -f 'bar.c' || echo '$(srcdir)/'`bar.c
>
> --
>
> Bruce Korb <first initial + last name at gnu dot org>
> AG URL: http://autogen.sourceforge.net
>
