Re: some general help needed

[Richard Ash]

On Fri, 2008-08-15 at 14:40 +0200, Matej Tyc wrote:
> Hello, 
> I would like to find answers to some questions that developers had to
> ask, but that are not answered in the right way.

I don't know what you have been reading, but the best extended reference
I have encountered is David MacKenzie's Autobook:
  http://sourceware.org/autobook/autobook/autobook.html

> 1. I have a project and I would like to add autotools (eg. ./configure
> --blablabla && make && make install) support. Of course, I have the
> source code, an idea how to compile it, I know roughly what to write to
> Makefile.am and configure.ac. 
> But I don't know:
>       a) What is some "standard root project directory layout" that doesn't
> cause problems and that everybody likes?
There isn't one - in most cases the layout seems to be locked long
before autotools arrive, so in practise autotools get adapted to fit
round what is already in place. Libtool of course places it's own
restrictions (like shoving a lot of files in .libs / _libs directories).
The only rule that is a real pain if it is broken is to ensure that
header layouts in the non-installed library match the installed layout -
so if you install a header as libfoo/bar.h (so you can write
<libfoo/bar.h> in the code that uses the lib), then make sure that in
your source tree you keep your headers in a libfoo subdirectory, so that
it is possible to add the package source directory to the include path
in order to link against the library without having to install it.

>       b) What is considered to be the smart way how to build documentation
> for the project? How to include doc build to autools setup?
This depends on what you choose as a documentation format. AC_CHECK_PROG
is probably you friend if your chosen tool doesn't provide it's own
macros for detecting it's presence.

>       c) How to deal with the fact that the project is multiplatform and the
> build process is not mplatform independent? 
In what way is the build not platform-independent? Apart from the
obvious lack of a compatible shell for windows by default ...?

If you need to select different source files or #defines for different
platforms, then it comes down to configure checks (strongly consider
using something other than the platform for the checks - e.g. check for
the ALSA audio header not for the target being Linux) which set compiler
flags, variables in the config header, or alter lists of source files
which are  substituted into makefile.in.

> 2. I have a library and I would like to make life easy for people that
> will use it and choose autotools to manage their projects. What is the
> standard/simple/portable/smart way how to do this? 
> I have seen a very long macro (AM_PATH_LIB(...)) and some script
> (lib-config) that hasn't always been working very well (problems with
> cross-compilation, ...) How you do this, please?
Libtool or pkg-config. Libtool is probably more powerful, but a pain if
you aren't using libtool and want to link against an uninstalled copy of
the library.

pkg-config is a lot simpler (basically generate the .pc files from
configure with AC_SUBST), but generally works perfectly well. It
certainly makes writing other configure scripts easy and quick, on the
other hand it is missing from Mac OS X by default (can be installed
however).

> What about an autotools wiki? Autotools are considered "arcane and hard
> to use." But it is mainly due to lack of documentation that young
> developers require, don't you think? 
There are already a lot of introductory guides on the web, just not in
one place. For learning another programming language, it's not bad for
documentation. Trying to find acceptable C documentation on the web is
much harder ...

Richard