2009/11/28 Юрий Пухальский <aikip...@gmail.com>: > On Fri, Nov 27, 2009 at 4:07 PM, Jack Kelly <endgame....@gmail.com> wrote: >> 2009/11/27 Юрий Пухальский <aikip...@gmail.com>: >>> 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/x...@xxx >>> 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. > 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. >>> 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. >> >> 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? That said, I could find no mention of cleaning up intermediates in http://www.opengroup.org/onlinepubs/9699919799/ , so perhaps it's nonstandard. 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). 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. Hope I'm helping. -- Jack
