Re: Mostly similar library generation

[Harlan Stenn]

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
>