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

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

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:)))

2011/1/11 Юрий Пухальский <address@hidden>:
> 2011/1/11 Ralf Wildenhues <address@hidden>:
>> Hello Юрий,
>>
>> * Юрий Пухальский wrote on Tue, Jan 11, 2011 at 03:48:08PM CET:
>>> I've (finally) made it through two implicit rules, but i have a problem 
>>> there.
>>>
>>> The makefile looks something like that:
>>>
>>> ------------------------
>>> .SUFFIXES: .pc .lo .c
>>> .pc.c:
>>>       cp $< $@
>>> .c.lo:
>>>       cp $< $@
>>> ------------------------
>>>
>>> Given that i have no .c and no .lo before invoking make, it works good
>>> with gmake and aix make.
>>> While on HP-UX it doesn't:
>>
>> Yep, that's because some non-GNU makes don't close suffix rules
>> transitively.  You can either add explicit stub dependencies
>>  foo.lo: foo.c
>>  bar.lo: bar.c
> They are too many... And this is a crud.
> But as i read a standard, i understand, the rules must be transitive.
> As there's stated that if there is no explicit rule, we use implicit,
> thus in this case requiring to rebuild foo.c. Then we apply the same
> logic and get to foo.pc to foo.c implicit rule, no?
>
>>  ...
>>
>> or you can add a .pc.lo rule that contains the commands from both other
>> rules.  Or require a decent make.  ;-)
> That was what i started with:) But as there were problems i was
> advised to use .pc.c rule...
>
>>
>> Cheers,
>> Ralf
>>
>
>
>
> --
> «The good thing about standards is there are so many to choose from.»
>
>
>
>



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