Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary

[Jack Kelly]

2009/11/28 Юрий Пухальский <address@hidden>:
> On Fri, Nov 27, 2009 at 4:07 PM, Jack Kelly <address@hidden> wrote:
>> 2009/11/27 Юрий Пухальский <address@hidden>:
>>> 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/address@hidden
>>> 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
>>
>> Because here ^ it needed to link against a libtool library. Did you
>> put ../../lib/common/libcommon.la in blabla_LDADD?
> Ah, true.
> Yes, it was in LDADD of course.
>
>>
>> (Also, if these are convenience libraries only, you can use
>> noinst_ARCHIVES instead and save yourself from compiling everything
>> twice.)
> Why compile everything twice?

Because libtool usually compiles things twice when turning a .foo into
a .lo: once for static libraries and once for shared libraries.
Automake cannot tell where a libtool convenience library is going to
be used and must build the objects for a shared library in case that
is what's used, even if not.

> And i don't see any such thing (_ARCHIVES) in the manual...

My bad. I meant noinst_LIBRARIES, so you make a libcommon.a instead of
libcommon.la. This goes into LDADD as with libtool convenience
libraries.

>>> 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.
>>
>> You still specify the .pc file in _SOURCES, but let make work out how
>> to make the .c file.
> Yes, the only thing remains how to clean up the intermediate file.
> gcc3.81 is fine (btw, doesn't clean up in my case, don't know why!),
> but we have a whole lot of unices some with their native makes, i have
> no time to delve into the standard, but i bet they're not required to
> be that smart, no?

I assume you mean make3.81 here.

>>
>> I made a simple test:
>> -snip-
> See above, mine 3.81 is not smart:) Maybe because is use LDADD with .la.

According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4073 ,
all it takes for a file not to be considered intermediate is for it to
have an explicit mention anywhere. Does your Makefile.am mention foo.c
anywhere?

That said, I could find no mention of cleaning up intermediates in
http://www.opengroup.org/onlinepubs/9699919799/ , so perhaps it's
nonstandard.

The behaviour described in the Debian bug also shows how deleting
intermediate files can be inefficient. I'm not sure if you're going to
run into that behaviour or not, which is not a bug in make.

>>
>>> 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 $@
>>
>> Just because two people do silly things doesn't make it less silly.
> Well, at least here's an explicit removal of an intermediate file. I
> cannot see how to achieve this in your approach, let alone the IQ of
> gmake:)

It seems like you just have to not mention the file explicitly as a
target or prerequisite.

If you really want to remove intermediate files, and you want this to
work on most makes, it looks like you need to do a suffix rule. Here
is my suggestion:

.pc.$(OBJEXT):
        $(PCC) $(PCCFLAGS) iname=$(srcdir)/$*.pc oname=$(builddir)/$*.c
        $(COMPILE) -c $*.c
        rm $*.c

See 
http://www.gnu.org/software/hello/manual/automake/Program-Variables.html#index-COMPILE-508
for an explanation of $(COMPILE).

The problem with this approach is that you won't be running the same
compile command as you will for your standard C files, because the
configure script selects one from several different options based on
what sort of dependency tracking was chosen. So if it depends on a
header or something and that header changes, it won't know to remake
foo.o from foo.c.

Also, if make gets interrupted after the call to $(PCC) but before the
call to $(COMPILE), you'll have the .c file hanging around, anyway.

I think my favoured approach would be to use a .pc.c rule. You'll get
correct dependency tracking and you can do cleanup by putting foo.c in
CLEANFILES.

Hope I'm helping.

-- Jack