Re: Re: configure.ac, Makefile.am question

[Tim Post]

On Thu, 2008-08-21 at 18:07 +0200, address@hidden wrote:
> Well till i get things running, i dont want to get anyone fiddle around with
> the build system, that's all. After that, i'd appreciate if anyone comes up
> with a patch, change whatever it is. Help is always welcomed to give
> and take.

This is just a friendly suggestion: Include your configure.in,
configure.ac, Makefile.am and some script named 'autogen.sh' to
reproduce the build system (i.e. invoking aclocal, automake, autoconf,
etc).

Tracking 'configure' itself in your repository presents problems:

1 - Its un-needed clutter

2 - People updating their svn / git / hg from your's may actually have
to solve merge conflicts in configure itself, which is a __major__ pain
in the butt. This happens if they have run 'autoreconf' themselves, or
similar.

3 - People will pick patches to configure, but ignore the underlying
changes to configure.in / configure.ac and wonder why it breaks.

4 - People with commit access to your repository will also have to
resolve merge conflicts in configure, no fun :(



So now we realize that we actually have several versions of the source
code, each one slightly different:

* The 'trunk' or bleeding edge code requires developers to generate the
build system themselves. 

* The 'source tgz' downloads contain configure, Makefile.in plus all of
the files needed to re-generate them. This is likely the file OS
packagers will use to package your program in the future.

* Branches of the repository might contain either / or, depending.

The GPL requires only that you make the source code available with all
files needed to complete the build. So, in essence, you could exclude
the things needed to rebuild the build system, but you would alienate
anyone who is willing to help you 'properize' it.

It sounds like, to me, you wish to exclude these files because you are
unsure of their correctness? The fastest and easiest way to fix that is
to publish them, even if broken then ask someone to try to reproduce the
build and send patches.

> Autotools are great (but a bit unbendable :} ) , and again many thanks !

Please realize that your trying to wrap your head around two very
complex tools at once, Autoconf and Automake. You are not going to
become an overnight 'guru' with either. In fact, the first time I used
Autoconf, I spent more time messing with Autoconf than I did writing the
program in the first place.

The best thing to do is publish it all, even if its broken and invite
others (even on this list) to tell you why its broken and how to fix it.

Best of luck with your project :)

--Tim

-- 
Monkey + Typewriter = Echoreply ( http://echoreply.us )