On Sat, 2008-08-16 at 10:50 +0200, Ralf Wildenhues wrote: Thank you for your replies. I have accumulated a list of very useful links that may help me to deal with the problem. For instance, John Calcote has sent me a link to his tutorial about autotools that I find exceedingly useful and that I haven't been able to google earlier: http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool I absolutely don't agree with the reasoning why not to have a wiki. Autotools don't have an official tutorial. Wiki is good since autotools are changing and wikis are easy to update. I am going to gather many useful experiences and I would like to post them to some place where they will be available for everyone for a long time and where they will be easy to find. The worst thing that can happen to a wiki is spam infestation, so why not to at least try it? It can be useful for many beings! I look forward to future colaboration Matej btw: Posts have "wrong" header in the way that when one replies to them, one will ommit the mailing list. I have received replies that went only to me and I made that mistake as well. Other mailing lists usually behave differently... So what do you think of this behavior? > Hi Matej, > > Besides what was already mentioned: > > * Matej Tyc wrote on Fri, Aug 15, 2008 at 02:40:53PM CEST: > > a) What is some "standard root project directory layout" that doesn't > > cause problems and that everybody likes? I have learned that it is good > > to have /src directory, /build-aux dir, /m4 dir and maybe /bin dir, all > > from different sources. Nothing "official" from experienced autotools > > users that would say 'Don't put your object files to the root since it > > becomes a terrible mess afterwards' (wxWidgets project behaves like > > this) > > Mostly a matter of taste. Having build-aux and m4 is good to keep many > helper files out of the way. > > Please allow to have the build tree completely separate from the source > tree. > > > b) What is considered to be the smart way how to build documentation > > for the project? How to include doc build to autools setup? > > Do you already have documentation in some form? > If not, consider what you and your peer developers are familiar with, > otherwise you can try texinfo. > > > c) How to deal with the fact that the project is multiplatform and the > > build process is not mplatform independent? > > Try to off-load as much of the platform dependencies to autoconf. > The GNU Coding Standards has some guidance, aside from the Autoconf > manual. More help here if you ask more specific questions. > > > 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? > > Use libtool and pkg-config. > > > 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 is a good tutorial at > <http://www.lrde.epita.fr/~adl/autotools.html>. > It's considerably newer and more up to date than the Autobook. > > Somebody has started writing on a new book recently IIRC. > > Requests for a wiki have come up before; one problem with a wiki is that > we felt that it would need to be maintained by somebody experienced. We > prefer that good advice end up in the manuals, or maybe in the above > tutorial > > > Please, don't underestimate user-friendliness! > > Good point. As a first, if you ask specific questions on what you tried > and what doesn't work, chances are really high you will be helped on > these lists. > > Cheers, > Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
