Re: Conditional compilation based on GSL version

[Ed Smith-Rowland <3dw4rd@verizon.net>]

M Joonas Pihlaja wrote:
> On Fri, 20 Feb 2009, Brian Gough wrote:
>
>   
>> At Thu, 19 Feb 2009 23:04:40 +0200 (EET),
>> M Joonas Pihlaja wrote:
>>     
>>> Could GSL expose some facility in gsl_version.h to compare the version 
>>> of GSL at compile time for dumb clients which don't want to impose 
>>> special build system requirements?  
>>>       
>
>   
>> I'd say the GNU approach to compatibility is to test for the 
>> presence of individual functions or features with autoconf, rather 
>> than package versions--it is more reliable in the long-term.  
>>     
>
> Where to draw the line though?  Should I check for the availability of 
> every single symbol I'm using from GSL?  Just the ones which I know 
> are volatile or new?  *shudder*  Versioning the API is a perfectly 
> valid solution to the problem and since GSL does have API stability, 
> why not make the version conveniently available to client programs as 
> well?
>
>   
>> So if you can use autoconf, I would recommend that.  If not, maybe 
>> you could describe the details of the situation a bit more.
>>     
>
> Of course.  I won't go into details on why I don't use autoconf for my 
> code, but suffice to say that it's about as portable as a pile of 
> bricks; doable with enough effort, but really inconvenient and not fun 
> at all.  #ifs work everywhere and have a minimal burden when kept 
> in check.
>
> The specific situation I'm looking at is simply that GSL implemented 
> missing complex vector operations in 1.12 which I'd like to export in 
> my GSL <-> Lua minibinding.  Autoconf doesn't even know what Lua is, 
> never mind what to do with it. :)
>
> Cheers,
>
> Joonas
>
>   
Autoconf might not know what Lua is but CMake might.
I played around with CMake ans it seemed easier than Autoconf and it was 
loaded with pre-built things for recognizing tons of stuff,

Good Luck,

Ed