[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Emilio Pozuelo Monfort
Date: Mon, 26 Jul 2010 19:45:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100619 Icedove/3.0.5


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]