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 Юрий Пухальский <aikip...@gmail.com>:
> 2011/1/11 Ralf Wildenhues <ralf.wildenh...@gmx.de>:
>> 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.»
