[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: check_version
From: |
Simon Josefsson |
Subject: |
Re: check_version |
Date: |
Thu, 14 Jul 2005 21:06:18 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
Bruno Haible <address@hidden> writes:
> Simon Josefsson wrote:
>> +const char *
>> +check_version (const char *req_version)
>> +{
>> + if (!req_version || strverscmp (req_version, VERSION) < 0)
>> + return VERSION;
>> +
>> + return NULL;
>> +}
>> ...
>> You will typically wrap the call to the
>> `check_version' function through a library API, your library header
>> file may contain:
>>
>> #define STRINGPREP_VERSION "0.5.18"
>> ...
>> extern const char *stringprep_check_version (const char *req_version);
>>
>> The implementation of `stringprep_check_version' would simply pass
>> on the call to `check_version'.
>
> This makes it impossible to have more than one package using the check_version
> function. Say, stringprep and libiconv want to use the check_version
> function. On an ELF system, only one of the two copies of it can persist.
> Such that a call to stringprep_check_version would end up comparing with
> libiconv's version, or vice versa. And on non-ELF systems, you could get
> a linker error.
Ouch. Thanks for the heads-up.
> I see only one way out: Recommend to use a config.h that does
> #define stringprep_check_version check_version
> instead of a function that calls check_version.
I assume you meant:
#define check_version stringprep_check_version
Perhaps check_version.c could be compiled with
-Dcheck_version=$(PACKAGE)_check_version? The gnulib module could set
something like that up, to avoid manual config.h additions.
Alternatively, check_version() could be modified to take the
PACKAGE_VERSION string as a parameter, passed on from
stringprep_check_version. But then it is almost as easy to call
strverscmp directly in stringprep_check_version.
Perhaps using strverscmp directly is simpler, and we can forget about
this module. I'm starting to lean towards that. Unless you, or
anyone else, have any further ideas on this, I think I will forget
about this module.
Thanks,
Simon