Re: autotools & prayertime

[Thamer Mahmoud <neokuwait at hotmail dot com>]

Nadim Shaikli writes:
 > Thamer, to preface my questions and comments let me say that I know
 > close to nothing about autotools/libtoolize beyond simply using 'em
 > (I've never had the pleasure (or whatever you want to call it :-) in
 > developing 'em).  I do have a few issues with the autotools on the
 > itl-prayertime lib specifically.
 > 
 > I'm on a SUN machine using solaris, so I'm not sure if this is a
 > portability issue or what, but here is a minimal description.
 > 
 >   $ make -f Makefile.cvs
 >   set -x
 >   aclocal
 >   aclocal: configure.in: 9: macro `AM_PROG_LIBTOOL' not found in library
 >   make: *** [all] Error 1
 > 
 > once I comment-out the variable above (just for grins) I see this,
 > 
 >   set -x
 >   aclocal
 >   libtoolize --force --copy
 >   Remember to add `AC_PROG_LIBTOOL' to `configure.in'.
 >   You should update your `aclocal.m4' by running aclocal.
 >   autoheader
 >   automake --add-missing --copy
 >   configure.in: installing `./install-sh'
 >   configure.in: installing `./mkinstalldirs'
 >   configure.in: installing `./missing'
 >   Makefile.am:12: Libtool library used but `LIBTOOL' is undefined
 >   Makefile.am:12: 
 >   Makefile.am:12: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
 >   Makefile.am:12: to `configure.in' and run `aclocal' and `autoconf' again.
 >   Makefile.am: installing `./compile'
 >   Makefile.am: installing `./depcomp'
 >   make: *** [all] Error 1
 > 
 > I then tried to create my own configure.in by running 'autoscan' and
 > that resulted in a completely different set of problems.  As noted,
 > I'm not familiar enough to know how to debug and correct these problems,
 > but I know I need to know more (chances are, I'll have to do the same
 > for the 'hijri' itl lib, etc).  

This is my first project with autotooling, so for now, I can't really
provide help (or comment) on debugging issues. Google for the error
message or try what Behdad suggested.

 > Do you have a short HOWTO or primer (not looking to read books and
 > 26 chapters on the topic :-)
 > 

Have a look at these simple library examples that I've used as my
starting point:
http://sources.redhat.com/autobook/convenience-1.0.tar.gz
http://sources.redhat.com/autobook/large-1.1.tar.gz

Also these pages are useful:
http://www.gnu.org/software/libtool/manual.html#SEC23
http://sources.redhat.com/autobook/autobook/autobook_283.html#SEC283


 > In passing, I believe the following suggestions might be of interest
 > (Elzubeir, this might of interest to you too since it affects the examples
 > in the developer guide),
 > 
 >  1. In Makefile.cvs make 'all' appear first instead of 'configure' - this
 >     will then simply run the autotools to create their output instead of
 >     forcing the user to run configure as well (he/she might not have
 >     intended to do that as well).
 > 

I copied this from the developer guidelines. Elzubeir might have a
better answer for it than me.


 >  2. Add a 'clean' option to the Makefile.cvs so that it goes back to the
 >     pristine condition things were in before running 'make -f Makefile.cvs'.
 > 
 >     In other words, rm all the intermediate files (autom4te.cache/, *.m4,
 >     compile, config-h.in, config.guess, config.sub, configure, depcomp,
 >     install-sh, ltmain.sh, missing, mkinstalldirs, etc) if one were to
 >     have compiled everything and wanted to revert back to the very
 >     beginning.
 > 
 >     a. Not sure if this is worth it, but try to remove things once they
 >        are done in the normal auto-generation process.


Adding this would be sufficient:

clean:
	make maintainer-clean
	rm -rf autom4te.cache
	rm -f aclocal.m4
	rm -f config-h.in
	rm -f configure
	rm -f config.sub config-h.in config.guess
	rm -f install-sh ltmain.sh
	rm -f mkinstalldirs missing
	rm -f stamp-h.in Makefile.in


 > 
 >  3. All projects that incorporate autotools (and all are going in that
 >     direction), then the projects should put all its source files in
 >     a ./src directory and the documentations in ./doc, etc.
 > 

I agree. Having a src/ doc/ is better then dumping it all into a
single directory. Also, I think the developer guidelines should
probably include a preferred directory structure for projects using
the autotools.

 > Using -- autoconf-2.57, automake-1.7.9, libtool-1.5
 > 
 > BTW: on linux I have no issues; the above 3 points would be nice to see.
 >      I also don't see 'fribidi' for instance using "libtoolize", is our
 >      process over-complicated compared to their 'bootstrap' ?
 > 
 > Just trying to learn...
 > 
 > Salam.
 > 
 >  - Nadim
 > 

Regards,

Thamer Mahmoud