Automake links binaries through libtool too, at least in my case.
-----make output-------
/oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include
include=/oracle/10.2.0.4/lib include=/usr/include ireclen=4800
oreclen=4800 select_error=no release_cursor=no hold_cursor=yes
lines=yes ltype=none cpp_suffix=c USERID=xxx/x...@xxx
SQLCHECK=SEMANTICS iname=./blabla.pc oname=./blabla.c
<ProC blabla skipped>
cc -DHAVE_CONFIG_H -I. -I../../include -g -DLINUX -Wall -W -MT
blabla.o -MD -MP -MF .deps/blabla.Tpo -c -o blabla.o blabla.c
mv -f .deps/blabla.Tpo .deps/blabla.Po
/bin/sh ../../libtool --tag=CC --mode=link cc -g -DLINUX -Wall -W
-L/oracle/10.2.0.4/lib -o blabla blabla.o
../../lib/common/libcommon.la ../../lib/pro_c/libproc.la -lclntsh
-lcurl -lssl -lxml2 -lEx25 -lEec -lpthread -lm
libtool: link: cc -g -DLINUX -Wall -W -o blabla blabla.o
-L/oracle/10.2.0.4/lib ../../lib/common/.libs/libcommon.a
../../lib/pro_c/.libs/libproc.a -lclntsh -lcurl -lssl -lxml2 -lEx25
-lEec -lpthread -lm
-----end of make output-------
And yes, it works when i make a rule from .pc to .c, but:
How do i clean the intermediate .c file in this case?
I must add BUILT_SOURCES everywhere, use EXTRA_DIST for distributing
the original files.
Generally it's less clear than specifying .pc file directly in _SOURCES.
As for silliness, it's exactly as silly as default .l.o implicit rule
in standard make:
.l.o:
$(LEX) $(LFLAGS) $<
$(CC) $(CFLAGS) -c lex.yy.c
rm -f lex.yy.c
mv lex.yy.o $@
2009/11/27 Jack Kelly <endgame....@gmail.com>:
> 2009/11/25 Юрий Пухальский <aikip...@gmail.com>:
>> Good day!
>>
>> As of automake 1.11 the following problem exists:
>> I have a nonstandard suffix .pc (ProC source), which i compile into .lo with
>> SUFFIXES = .pc
>> .pc.lo:
>> $(PCC) $(PCCFLAGS) iname=$(srcdir)/$*.pc oname=$(builddir)/$*.c
>> $(LIBTOOL) --tag=CC --mode=compile $(CC) $(AM_CPPFLAGS) $(CFLAGS)
>> -...@top_srcdir@/include -c $(builddir)/$*.c
>> rm -f $(builddir)/$*.c
>>
>> When i try to make a binary with
>> bin_PROGRAMS = blabla
>> blabla_SOURCES = 1.c 2.c 3.pc
>>
>> the part of Makefile.in is:
>> am_blabla_OBJECTS = 1.$(OBJEXT) 2.$(OBJEXT)
>> blabla_OBJECTS = $(am_blabla_OBJECTS)
>> blabla$(EXEEXT): $(blabla_OBJECTS) $(blabla_DEPENDENCIES)
>> @rm -f blabla$(EXEEXT)
>> $(LINK) $(blabla_OBJECTS) $(blabla_LDADD) $(LIBS)
>>
>> There is one thing of interest: when making libtool library (.la),
>> everything works fine, .pc sources get compiled in!
>
> I think this is why (uneducated guess follows):
>
> When compiling a PROGRAM which doesn't need libtool (i.e., not linking
> against a libtool library), it will compile foo.c (or whatever) to
> foo.$(OBJEXT) (usually foo.o). You only have a suffix rule to build a
> .lo from a .pc, so when it tries to make a libtool library (which
> links libtool object (.lo) together), it will compile 3.pc into 3.lo
> and link.
>
> Going from .pc to .lo seems silly. Can you try going from .pc to .c,
> and let make go from .c to .whatever-it-needs (.o, .lo, .banana,
> whatever)?
>
> .pc.c:
> $(PCC) $(PCCFLAGS) iname=$< oname=$@
>
> -- Jack
>
>
>
--
«The good thing about standards is there are so many to choose from.»
