2009/11/28 Jack Kelly <endgame....@gmail.com>: > 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. Ah, well, i'm unusual, i use disable-shared anyway:)
> >> 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. I haven't checked it, but does it support library dependencies like .la? This i use extensively. > >>>> 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. Oh, yes, exactly:) > >>> >>> 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? I shall check it on monday extensively, and finish reading that thread also. > > That said, I could find no mention of cleaning up intermediates in > http://www.opengroup.org/onlinepubs/9699919799/ , so perhaps it's > nonstandard. >From my investigation i tend to agree:) > > 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). Ah, that's what i should have done, seems i'm a bit outdated... But the idea was like this. > > 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. Cleanup yes, but without cleanup they shall be hanging around anyway. I shall consider the opportunities. I'm changing the build system of a certain project and have coded is verbatim more or less. To be closer to what has been. And because i'm outdated, i have chosen to remove intermediate files, because the implicit make rules are sucked in with mother's milk, so to say... > > Hope I'm helping. > > -- Jack > > > -- «The good thing about standards is there are so many to choose from.»
