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 <stefano.lattar...@gmail.com>: > 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.»
