Hi! On Thu, 10 Nov 2011 04:49:25 +0100, Guillem Jover <[email protected]> wrote: > On Tue, 2011-11-08 at 00:13:51 +0100, Thomas Schwinge wrote: > > In GNU Mach, we have a version.m4 where these fields are defined one and > > for all. (I argue that a package's version definition does not really > > belong into a generic, otherwise version-agnostic configuration system's > > file.) (But on the other hand, *version*.m4 is likely not the most > > suitable name for defining a package's name.) (Are we bike-shedding > > yet?) > > I introduced that file because at the time the source tree had multiple > configure.in, so sharing the definitions seemed saner. But then this > could have been merged back once the build system was converted to a > single configure.ac. The attached patch does just that.
Well, it still does make some sense to me to decouple a package's vital definitions (name, version, etc.) from the build machinery. So I would not change anything. But if people prefer to get rid of the version.m4 file (or not introduce it in the Hurd case), then I don't boycott that either. Ludovic can then do the equivalent thing for GNU Hurd. > Regarding the definition of the version, I tend to agree, and I'd say > it should be generated automatically from the nearest git tag (but > then gnumach does not have any tags right now :). We can easily have such tags for future releases, and I'd also review any proposed SHA1s for tagging past releases. > There's such a script > in gnulib (git-version-gen) that could be used, if GPL3+ would be an > issue I implemented a similar one but GPL2+ for dpkg (get-version) > some time ago. Grüße, Thomas
pgpN3TBf77Blp.pgp
Description: PGP signature
