[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH gnumach] Inline version.m4 into configure.ac
From: |
Guillem Jover |
Subject: |
Re: [PATCH gnumach] Inline version.m4 into configure.ac |
Date: |
Sat, 12 Nov 2011 05:52:12 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, 2011-11-10 at 12:02:38 +0100, Thomas Schwinge wrote:
> On Thu, 10 Nov 2011 04:49:25 +0100, Guillem Jover <guillem@hadrons.org> wrote:
> > 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.
I don't see how the project information (name, version, bug address,
etc) is more vital than the build infrastructure, also they are both
pretty project specific so not something that would ease reuse in any
case.
> > 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.
Here's a first batch, some of those are based on the latest change to
the =announce-N.N files which might seem to be post-release, I could
provide instead the ones that last modified the version number, but
that does not seem more accurate, I guess the most correct would be
to compare against released tarballs. Anyway here it is:
f07a4c844da9f0ecae5bbee1ab94be56505f26f7 gnumach-0.2
caf359e521041e7aa6290aa04225e974f73befd2 gnumach-1.0
7b70f5576a910fab0de137cf9bce849602a17b54 gnumach-1.1
6402504b0db6c64db36b6bfe4a0a57f4c2606520 gnumach-1.1.1
1091d287bad2ce66223ad975dca4b54281ee83ba gnumach-1.1.2
0bfb893719095ca79b7337d994b6220b6823d690 gnumach-1.1.3
129475fe1c546bd7db86e8410ca48f3612e0a80e gnumach-1.1.92
ca26c4b94f9fe653d4c50a7981e74bd1d21242ca gnumach-1.2
4fd7c820be7a860e8cb93acb629db028f08ba71c gnumach-1.3
thanks,
guillem
- [PATCH] Provide modern Autoconf initialization, Ludovic Courtès, 2011/11/07
- Re: [PATCH] Provide modern Autoconf initialization, Samuel Thibault, 2011/11/07
- Re: [PATCH] Provide modern Autoconf initialization, Ludovic Courtès, 2011/11/07
- [PATCH gnumach] Inline version.m4 into configure.ac, Guillem Jover, 2011/11/09
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Thomas Schwinge, 2011/11/10
- Re: [PATCH gnumach] Inline version.m4 into configure.ac,
Guillem Jover <=
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Svante Signell, 2011/11/12
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Ludovic Courtès, 2011/11/12
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Ludovic Courtès, 2011/11/10
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Thomas Schwinge, 2011/11/20
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Guillem Jover, 2011/11/20
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Ludovic Courtès, 2011/11/20
- Re: [PATCH gnumach] Inline version.m4 into configure.ac, Thomas Schwinge, 2011/11/20
- Re: [PATCH] Provide modern Autoconf initialization, Thomas Schwinge, 2011/11/10
- Re: [PATCH] Provide modern Autoconf initialization, Ludovic Courtès, 2011/11/11
- Re: [PATCH] Provide modern Autoconf initialization, Thomas Schwinge, 2011/11/20