[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mostly similar library generation

From: Harlan Stenn
Subject: Re: Mostly similar library generation
Date: Mon, 15 Apr 2002 23:38:47 -0400


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 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 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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]