minimal required version of (optional) tools

[Greg Banks]

On Mon, Jul 2, 2012, at 09:53 AM, Дилян Палаузов wrote:
> Hello,
> 
> > 1) if we have any doubts about the version of tools needed to generate
> > parts of the source, then ship the generated source in the dist tarball
> > and hide the make rules in maintainer mode.  The code should be
> > buildable from a dist tarball on the widest possible range of platforms.
> 
> I am talking about maintainer mode.  The distributed tarballs contain 
> anyway the generated files and as long as the input files (e.g. 
> sieve/addr-lex.l are not changed, the Makefile-rules are not invoked and 
> it does not matter, if the tool is available or not.

Great, we're all good then :)

> > 2) For maintainer mode, the ideal situation is that versions of tools
> > available in the current Long Term Support releases of common target
> > platforms should work without difficulty.
> 
> Which versions of autoconf, automake, bison, (f)lex, gperf and libtool 
> are in the current Long Term Support releases of common target platforms?

That's where *you* get to do the research.

Me, I'm lazy.  I usually start by setting the minimum version to the
version on my desktop and then decrease it any time I see a problem I
can't work around or a machine where I can't upgrade the tools.    But
then I don't usually go and rewrite an entire build system of a
non-trivial project, not after the great CML2 disaster of 2001 :)

> Why for maintainer mode it is not possible to stick to versions, that 
> are not yet in the Long Term Support releases?

Because maintainer mode is really "anyone who changes the source code in
a .y file" mode rather than "the mode for people with write access to
the Cyrus git repo".   I don't think it's good policy in an open source
project to put an artificial speed hump in the way of users contributing
patches (compilable, tested patches).  Given that we're a server
project, the users I'm thinking of are mail system admins.  A
significant portion of those folks want stable dependable supported
platforms, which is what Long Term Support releases are all about. 
FastMail doesn't operate like that, but lots of people who could be
contributing do.

In short, it's wonderful to have the latest flashy tool feature, but if
only two people in the world can build from git then we've got a
problem!

Remember, these are just my suggestions for rules of thumb, I'm not the
final arbiter.

-- 
Greg.