[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Bump HURD_INTERFACE_VERSION
From: |
Emilio Pozuelo Monfort |
Subject: |
Re: [PATCH] Bump HURD_INTERFACE_VERSION |
Date: |
Mon, 26 Jul 2010 19:45:46 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100619 Icedove/3.0.5 |
Hi,
On 23/07/10 11:24, olafBuddenhagen@gmx.net wrote:
> On Mon, Jul 19, 2010 at 10:57:48AM +0200, Thomas Schwinge wrote:
>> On Fri, Jul 16, 2010 at 12:19:21PM +0200, Emilio Pozuelo Monfort wrote:
>
>>> * hurd/version.h (HURD_INTERFACE_VERSION): Bumped for the
>>> recently added RPCs.
>>
>> I don't see a need for doing this unless you conditionalize anything on
>> the increased version number. The only example that I can find where
>> this is done, is [glibc]/sysdeps/mach/hurd/configure.in for the ``new
>> Hurd RPC interfaces supporting 64-bit file sizes'' (ChangeLog.13).
>>
>> Perhaps we should get rid of this one-dimensional scalar, and only use
>> real functionality probes instead?
>
> Indeed, that's what I suggested last time this topic came up. A linear
> interface version number doesn't make much sense with a non-linear
> development/deployment model...
>
> Of course checking individual interface changes requires coming up with
> a good autoconf test for the new interfaces. I hope Emilio already
> started an extra thread on this...
I asked Thomas on irc (as the autoconf expert), but I guess he missed the
question. So Thomas, any idea on how to check for a Hurd RPC reliably?
> Also, what to do with the existing interface version number? Update it
> nevertheless for any new interfaces? Leave it there but don't ever
> update it? Drop it alltogether?
IMHO either we remove it, or we update it with every interface change.
Regards,
Emilio