Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

* Michel Briand wrote on Wed, Aug 27, 2008 at 03:19:24AM CEST:
> Ralf Wildenhues <address@hidden> - Tue, 26 Aug 2008 17:43:13 +0200
> >* Michel Briand wrote on Tue, Aug 26, 2008 at 05:09:34PM CEST:
> >>
> >> What do you think of my example ? Is it useful for other people
> >> to learn autotools ?
> >
> >I don't know.  Typically, I'm bad at guessing what beginners need in
> >order to learn.
> 
> Writing this complete example was for me a wonderful learning
> experience. I hope that this template could help the maximum of new
> users of GNU build system.

Well, do you think it's the finished template or the fact that you've
written it from scratch, that helped you learn better?  If the latter,
then other new users won't benefit as much from reading the template.

> >> autoreconf --force --install -I config -I m4
> >
> >Why '-I config -I m4'?  AFAICS you do not use AC_CONFIG_MACRO_DIR([m4])
> >in configure.ac.  I'd use that, and drop '-I config'.
> >
> 
> I do not use the macro you mention.

Please do, though.  When you do, please also add
  ACLOCAL_AMFLAGS = -I m4

to the toplevel Makefile.am.

> So I can drop '-I m4' and have this
> command:
> 
> autoreconf --force --install -I config
> 
> But, I also use AC_CONFIG_AUX_DIR([config]). So may I cut '-I config'
> and have finally ?:
> 
> autoreconf --force --install

Yes.

> >> # Version: simpliest way to implement versioning
> >> PROGRAM_VERSION=`cat PROGRAM_VERSION`
> >> AC_SUBST(PROGRAM_VERSION)
> >> LIBRARY_VERSION=`cat LIBRARY_VERSION`
> >> AC_SUBST(LIBRARY_VERSION)
> >
> >These statements cause config.status output to be dependent upon the
> >files PROGRAM_VERSION and LIBRARY_VERSION.  Thus, I would add
> >  CONFIG_STATUS_DEPENDENCIES='$(top_srcdir)/PROGRAM_VERSION 
> > $(top_srcdir)/LIBRARY_VERSION'
> >  AC_SUBST([CONFIG_STATUS_DEPENDENCIES])
> >
> >so that configure is automatically rerun when those files change.
> >
> 
> Thank you for this tip ! But know I see I must instruct automake to
> rebuild the library if the file LIBRARY_VERSION changes. And the
> program is the file PROGRAM_VERSION changes...
> 
> Should I use the <>_DEPENDENCIES variable ?

Yes, I think I addressed that later in the message.

> >> # C++ is not used, so related checks are not needed
> >> m4_defun([_LT_AC_LANG_CXX_CONFIG], [:])
> >> # Same for Fortran
> >> m4_defun([_LT_AC_LANG_F77_CONFIG], [:])
> >
> >The above four lines are obsolete once you update your Libtool to a
> >version newer than 2.1.  So why even include them in a beginners'
> >document?
> 
> Debian (stable, testing, unstable) ships with libtool 1.5. So I have to
> take care.

Let's just hope lenny isn't far away any more.

> I can't use libtool 2.x now but I've seen in the
> documentation many improvements like this :))). I hope this is
> equivalent to the new useful LT_INIT and LT_LANG declarations.

AC_PROG_LIBTOOL is mostly equivalent to LT_INIT.  You won't need to use
LT_LANG yourself in most setups.  (Libtool will infer the needed
languages from the AC_PROG_{CC,CXX,FC,F77} and AM_PROG_GCJ macros you
use.

> >> AM_CPPFLAGS = -DLIBRARY_VERSION=\"$(LIBRARY_VERSION)\"
> >
> >Why not put
> >  AC_DEFINE([LIBRARY_VERSION], ...)
> >
> >in configure.ac, so you don't need the above?  Of course you may want to
> >use a less generic name, e.g. TRAINING_LIBRARY_VERSION.

> OK. That's a lot more concise. But having done this:
> 
> # Step 1: extract version number from a source file
> TRAINING_PROGRAM_VERSION=`cat PROGRAM_VERSION`
> # Step 2: export this variable to Makefile
> AC_SUBST(TRAINING_PROGRAM_VERSION)
> # Step 3: export this variable as a C define (config.h)
> AC_DEFINE([TRAINING_PROGRAM_VERSION], TRAINING_PROGRAM_VERSION, Program's 
> version)
> 
> I've seen that this don't work. And I've changed AC_DEFINE by
> AC_DEFINE_UNQUOTED. And it works like this:
> 
> AC_DEFINE_UNQUOTED([TRAINING_PROGRAM_VERSION], "${TRAINING_PROGRAM_VERSION}", 
> [Program's version])

Ah, sorry for mentioning AC_DEFINE, of course AC_DEFINE_UNQUOTED is
right.

> But I suspect there is some redundancy there in. Is this the better way
> to do that ?

I don't see one right away.

[ prog_DEPENDENCIES... ]
> >FWIW, you could actually add ../../LIBRARY_VERSION to this variable.
> 
> Yes, it works well too. I'll have all my dependencies handled that way.
> 
> But working a little with it, I have one remark: 
> 
> since, with AC_DEFINE, the version is stored in config.h and that all
> source files depend on it, all my C files are rebuild (in lib or bin)
> if I change the version file. The smart dependency is lost. So I'll
> remove library's and program's versions from config.h and rely on the
> old define on the command line. That's better for my need.

I agree with this analysis.  Didn't see that myself.

> Last, but not the least: autotools documentation that can be found on
> the web seems to obsoletes rapidly. There is the famous autobook that's
> not maintained anymore [1] and some info2www documentation [2], [3].
> 
> GNU/FSF should take a tour in this corner: improving / collection all
> the documentation on the (new & refreshed) gnu.org website.

Olly replied to you, and mentioned Alexandre's tutorial.  It's really
the most up to date one, and quite nice.  Please try it out.  We mention
it in the manual, I'm not sure whether we should mention it even more
prominently.

Cheers,
Ralf