* Conditional compilation based on GSL version
@ 2009-02-19 21:04 M Joonas Pihlaja
2009-02-20 9:54 ` Brian Gough
0 siblings, 1 reply; 5+ messages in thread
From: M Joonas Pihlaja @ 2009-02-19 21:04 UTC (permalink / raw)
To: gsl-discuss
Hi,
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? The current GSL_VERSION define
exports a string like "1.12", but that's not so useful for testing
against versions using the C preprocessor at compile time. Something
simple like GSL_VERSION_MAJOR and GSL_VERSION_MINOR defines would go a
long way. Or perhaps a more complex macro like
GSL_VERSION_IS_COMPATIBLE(major,minor) would be preferable.
My current workaround is to grab the GSL version string using
pkg-config, split it into major and minor version numbers, and pass
those in as preprocessor defines. It's rather ugly, possibly error
prone, and of course there's also the pkg-config requirement, so it's
not really ideal. I did look in the manual, but if I'm missing the
obvious solution please whack me with your stout clue stick. :)
Cheers,
Joonas
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Conditional compilation based on GSL version
2009-02-19 21:04 Conditional compilation based on GSL version M Joonas Pihlaja
@ 2009-02-20 9:54 ` Brian Gough
2009-02-20 12:10 ` M Joonas Pihlaja
0 siblings, 1 reply; 5+ messages in thread
From: Brian Gough @ 2009-02-20 9:54 UTC (permalink / raw)
To: M Joonas Pihlaja; +Cc: gsl-discuss
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? The current GSL_VERSION define
> exports a string like "1.12", but that's not so useful for testing
> against versions using the C preprocessor at compile time. Something
> simple like GSL_VERSION_MAJOR and GSL_VERSION_MINOR defines would go a
> long way. Or perhaps a more complex macro like
> GSL_VERSION_IS_COMPATIBLE(major,minor) would be preferable.
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. So if you can use
autoconf, I would recommend that. If not, maybe you could describe
the details of the situation a bit more.
--
Brian Gough
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Conditional compilation based on GSL version
2009-02-20 9:54 ` Brian Gough
@ 2009-02-20 12:10 ` M Joonas Pihlaja
2009-02-20 12:23 ` Ed Smith-Rowland
2009-02-23 19:54 ` Brian Gough
0 siblings, 2 replies; 5+ messages in thread
From: M Joonas Pihlaja @ 2009-02-20 12:10 UTC (permalink / raw)
To: Brian Gough; +Cc: gsl-discuss
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Conditional compilation based on GSL version
2009-02-20 12:10 ` M Joonas Pihlaja
@ 2009-02-20 12:23 ` Ed Smith-Rowland
2009-02-23 19:54 ` Brian Gough
1 sibling, 0 replies; 5+ messages in thread
From: Ed Smith-Rowland @ 2009-02-20 12:23 UTC (permalink / raw)
To: M Joonas Pihlaja; +Cc: Brian Gough, gsl-discuss
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Conditional compilation based on GSL version
2009-02-20 12:10 ` M Joonas Pihlaja
2009-02-20 12:23 ` Ed Smith-Rowland
@ 2009-02-23 19:54 ` Brian Gough
1 sibling, 0 replies; 5+ messages in thread
From: Brian Gough @ 2009-02-23 19:54 UTC (permalink / raw)
To: M Joonas Pihlaja; +Cc: gsl-discuss
At Fri, 20 Feb 2009 14:09:40 +0200 (EET),
M Joonas Pihlaja wrote:
> 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. :)
Ah, wrapping the whole library is a different case from what I was
thinking of--an application using some specific functions.
It could be useful to have those version numbers in the header but as
they aren't in any of the old ones I guess it is not really worth
adding them now.
Expanding GSL_VERSION using the C preprocessor on the gsl header file
is one way that doesn't require those package config scripts.
--
Brian Gough
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-02-23 19:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-19 21:04 Conditional compilation based on GSL version M Joonas Pihlaja
2009-02-20 9:54 ` Brian Gough
2009-02-20 12:10 ` M Joonas Pihlaja
2009-02-20 12:23 ` Ed Smith-Rowland
2009-02-23 19:54 ` Brian Gough
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).