From: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
To: Brian Gough <bjg@gnu.org>
Cc: gsl-discuss@sources.redhat.com
Subject: Re: Conditional compilation based on GSL version
Date: Fri, 20 Feb 2009 12:10:00 -0000 [thread overview]
Message-ID: <Pine.OSF.4.61.0902201255250.510753@sirppi.helsinki.fi> (raw)
In-Reply-To: <m3bpsxzcbp.wl%bjg@network-theory.co.uk>
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
next prev parent reply other threads:[~2009-02-20 12:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 21:04 M Joonas Pihlaja
2009-02-20 9:54 ` Brian Gough
2009-02-20 12:10 ` M Joonas Pihlaja [this message]
2009-02-20 12:23 ` Ed Smith-Rowland
2009-02-23 19:54 ` Brian Gough
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.OSF.4.61.0902201255250.510753@sirppi.helsinki.fi \
--to=jpihlaja@cc.helsinki.fi \
--cc=bjg@gnu.org \
--cc=gsl-discuss@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).