On Mon, Jul 2, 2012, at 07:09 PM, 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.
Neither am I, though I have a pretty strong vote ;) It seems to me we shouldn't need the fanciest brand new features. We aren't doing anything cutting edge. And the makefiles we ship with release tarballs better bloody work everywhere or the panda will be sad. Bron. -- Bron Gondwana br...@fastmail.fm
