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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
