Hello, to my opinion there are two things:
1. What do people cloning from git need in order to build the package 2. What tools versions do developers need, when they change a e.g. lex file.About people cloning from git, if we want to make their life easier, we can version-manage the generated files (e.g. sieve/addr-lex.c, Makefile.in) and that's all - no tools are really necessary.
About requirements for developers changing the Makefile.am or flex files, or even the autoconf input... Well about autoconf, if somebody is able to make changes in autoconf input (configure.ac and cmulocal/), then she shall be able to locally install the latest version of autoconf (under ~/bin or /usr/local/bin), so the highest version of autoconf could be required. About automake 1.12 and flex 2.5.35, provided that we are talking not about everybody who clones over git, but for those modifying sieve/addr-lex.l, sieve/sieve-lex.l or Makefile.am files, these people are soo few, that it is not necessary to talk about the Long Term Support releases.
Със здраве Дилян On 02.07.2012 11:09, Greg Banks wrote:
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.
<<attachment: dilyan_palauzov.vcf>>
