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

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

2009/11/28 Jack Kelly <address@hidden>:
> 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.
Ah, well, i'm unusual, i use disable-shared anyway:)

>
>> 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.
I haven't checked it, but does it support library dependencies like
.la? This i use extensively.
>
>>>> 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.
Oh, yes, exactly:)

>
>>>
>>> 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?
I shall check it on monday extensively, and finish reading that thread also.

>
> That said, I could find no mention of cleaning up intermediates in
> http://www.opengroup.org/onlinepubs/9699919799/ , so perhaps it's
> nonstandard.
>From my investigation i tend to agree:)

>
> 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).
Ah, that's what i should have done, seems i'm a bit outdated... But
the idea was like this.

>
> 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.
Cleanup yes, but without cleanup they shall be hanging around anyway.
I shall consider the opportunities. I'm changing the
build system of a certain project and have coded is verbatim more or
less. To be closer to what has been. And because i'm outdated, i have
chosen to remove intermediate files, because the implicit make rules
are sucked in with mother's milk, so to say...

>
> Hope I'm helping.
>
> -- Jack
>
>
>



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