Subject: Re: bug#7824: 1.11 doesn't add sources with nonstandard suffixes when making a binary

From: Юрий Пухальский <[email-masked]>
Date: Wed, 12 Jan 2011 18:28:10 +0300

Aye, looks like it.

I have no objections whatsoever, i just need some method to make it
work, because it's my working project:)
So no problem with me to join together these reports.

2011/1/12 Stefano Lattarini <[email-masked]>:
> Hello Юрий.
>
> On Wednesday 12 January 2011, Юрий Пухальский wrote:
>> So i put it all together.
>>
>> If i have a Makefile like this:
>> -----------------------------
>> SUFFIXES = .pc
>>
>> .pc.lo:
>>       cp $(srcdir)/$*.pc $(builddir)/$*.c
>>       $(LTCOMPILE) -c $(builddir)/$*.c
>>       rm -f $(builddir)/$*.c
>>
>> noinst_PROGRAMS = 1 2
>>
>> 1_SOURCES = 1.pc
>>
>> db_src = 1.pc
>> 2_SOURCES = dummy.c
>> 2_LDADD = $(db_src:.pc=.lo)
>> -----------------------------
>> 1 is not built:
>> --------------------------------
>> devfe:~/tmp/test>make
>> /bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2   -o 1
>> libtool: link: gcc -g -O2 -o 1
>> gcc: no input files
>> make: *** [1] Error 1
>> --------------------------------
>>
>> If i make a rule .pc.c, then i have problem on HP-UX.
>>
>> I'd say the first approach is legitimate - i make whatever rule i
>> want, i use .pc in SOURCES, and automake should take care of
>> everything else, like it's stated in the doc?
>> Second approach is ok too - for i don't see any limitation on
>> transitive rules in standard.
>>
>> On the other hand, putting explicit dependencies in case of makes like
>> that on HP-UX could be done in automake. It's cruddy to do it
>> manually...
>>
>> Can You comment on this?
>>
>> PS. If one can use a decent make, there is no need for automake:)))
>>
> Just a quick note: you might want to take a look at automake bug#7670:
>  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7670>
>  <http://lists.gnu.org/archive/html/bug-automake/2010-12/msg00034.html>
> which is closely related to yours.
>
> (BTW, these two bug reports are so similar that they should probably
> be merged).
>
> Regards,
>  Stefano
>

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