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

[Юрий Пухальский]

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?
And i don't see any such thing (_ARCHIVES) in the manual...

>> 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 made a simple test:
>
> --------------------
> bin_PROGRAMS = foo
> foo_SOURCES = bar.xyz
>
> SUFFIXES = .xyz
> .xyz.c:
>        cp $< $@
> --------------------
>
> Here is the make output:
>
> ----------------------
> $ make
> cp bar.xyz bar.c
> gcc -DPACKAGE_NAME=\"FULL-PACKAGE-NAME\"
> -DPACKAGE_TARNAME=\"full-package-name\" -DPACKAGE_VERSION=\"VERSION\"
> -DPACKAGE_STRING=\"FULL-PACKAGE-NAME\ VERSION\"
> -DPACKAGE_BUGREPORT=\"BUG-REPORT-ADDRESS\"
> -DPACKAGE=\"full-package-name\" -DVERSION=\"VERSION\" -I.     -g -O2
> -MT bar.o -MD -MP -MF .deps/bar.Tpo -c -o bar.o bar.c
> mv -f .deps/bar.Tpo .deps/bar.Po
> gcc  -g -O2   -o foo bar.o
> rm bar.c
> ---------------------
>
> Behold: Make (GNU Make 3.81 here) is smart enough to see that bar.c is
> a temporary file and remove it when finished.
See above, mine 3.81 is not smart:) Maybe because is use LDADD with .la.

>
>> 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:)
Frankly i don't like explicit libtool string for .c.lo in that case
either, but...

>
> -- Jack
>
>
>



-- 
«The good thing about standards is there are so many to choose from.»