[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [automake] Dependency question with _LDADD

From: Michel Briand
Subject: Re: [automake] Dependency question with _LDADD
Date: Wed, 27 Aug 2008 03:19:24 +0200

Great answer Ralf, thank you very much.

My updates / discussion below :).

Ralf Wildenhues <address@hidden> - Tue, 26 Aug 2008 17:43:13

>Hello Michel,
>can we limit followups to the automake list only, please?
>* Michel Briand wrote on Tue, Aug 26, 2008 at 05:09:34PM CEST:
>> as an exercise I decided to learn the maximum about automake and
>> libtool, and write a complete example.
>Thanks.  Some nits below.
>> 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.

>> I implemented library & program versioning. Basically.
>> I also modified the program's to not rebuild the program
>> when the library was just rebuilt.
>I don't think showing that to a beginner is a good idea.  It's certainly
>safer to let the program be rebuilt when the library changes.  But see
>below for more specific remarks.

I agree.

>Here's a bit of review:
>> ::::::::::::::
>> ::::::::::::::
>> autoreconf --force --install -I config -I m4
>Why '-I config -I m4'?  AFAICS you do not use AC_CONFIG_MACRO_DIR([m4])
>in  I'd use that, and drop '-I config'.

I do not use the macro you mention. So I can drop '-I m4' and have this

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

>> ::::::::::::::
>> ::::::::::::::
>> AC_INIT([autotraining], [1.0], address@hidden)
>> AC_CONFIG_AUX_DIR(config)
>If you aim at beginners, teach them the right manners by consistently
>using correct m4 quotation:
>  AC_CONFIG_AUX_DIR([config])


Also, being bored of lot of output during make (all defines are passed
on the compiler's command line) I decided to implement the config.h





#  include <config.h>

  to C files.

I don't know right now if I'll need a But that's more C
related that autotools related, I think...

>> # Version: simpliest way to implement versioning
>These statements cause config.status output to be dependent upon the
>files PROGRAM_VERSION and LIBRARY_VERSION.  Thus, I would add
> $(top_srcdir)/LIBRARY_VERSION'
>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 ?

>> # 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'

Debian (stable, testing, unstable) ships with libtool 1.5. So I have to
take care. 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.

>This macro has been spelled AC_PROG_LIBTOOL for years, and LT_INIT since
>Libtool 2.2.  Might want to at least use the AC_* form for clarity,
>otherwise your adept reader might search needlessly.


>> ::::::::::::::
>> src/lib/
>> ::::::::::::::
>> # Library: libtraining
>> # Generates its own pkg-config definition file
>Why not put
>in, so you don't need the above?  Of course you may want to
>use a less generic name, e.g. TRAINING_LIBRARY_VERSION.
>Similar applies to -DPROGRAM_VERSION in src/bin/

OK. That's a lot more concise. But having done this:

# Step 1: extract version number from a source file
# Step 2: export this variable to Makefile
# Step 3: export this variable as a C define (config.h)

I've seen that this don't work. And I've changed AC_DEFINE by
AC_DEFINE_UNQUOTED. And it works like this:

[Program's version])

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

>> pkgconfigdir = $(libdir)/pkgconfig
>> pkgconfig_DATA = libtraining.pc
>> libtraining_la_includedir = $(includedir)
>> libtraining_la_include_HEADERS = libtraining.h
>For what it's worth, I'd replace the two lines above with this one line
>  include_HEADERS = libtraining.h
>> libtraining_la_SOURCES = training.c
>Since you're making an example package, how about adding an uninstalled
>header here:
>  libtraining_la_SOURCES = training.c internal_header.h
>so that users know where to add that?
>> libtraining_la_LDFLAGS = -version-info ${LIBRARY_VERSION}
>> ::::::::::::::
>> src/bin/
>> ::::::::::::::
>> # Main program: training
>> # Uses libtraining in ../lib
>Please drop this line.
>> bin_PROGRAMS = training
>> training_SOURCES = training.c
>> training_LDADD = -ltraining
>This last line is wrong, too.  The two *have* to be replaced with this
>one line:
>  training_LDADD = ../lib/


>Why?  Because otherwise, paths to the uninstalled $builddir/src/lib may
>end up in the installed binary on some systems.  That can be a security
>issue.  If you want to work around the rebuilding issue, then *please*
>guard it with a big fat comment that this isn't for the faint of the
>heart, and should not be done typically.  And then do it like this:
>  # Explicitly override the dependency on any libraries, to hack away
>  # automatic rebuilds.  Done because the author knows better than to
>  # change the library incompatibly:
>  training_DEPENDENCIES =

It works :). Nice.

>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. But I wait
for you comments/tips on the AC_DEFINE I showed earlier in this mail.

>I should note that when I encounter newbies reporting bugs against
>autotools, which turn out to have broken builds due to this setting
>of yours, I will gladly send them to you.

OK. But when this exercise will be finishes (I hope to have all
autotools files at best), I'll concentrate on the program I write :))

Anyway I can contribute by answering to mails with respect to my
duties :).

>Hope that helps.

Thank you very much.

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) website.



: :' :  We are Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-    our own. Resistance is futile.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]