From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31073 invoked by alias); 20 Feb 2009 12:10:08 -0000 Received: (qmail 31063 invoked by uid 22791); 20 Feb 2009 12:10:08 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sirppi.helsinki.fi (HELO sirppi.helsinki.fi) (128.214.205.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Feb 2009 12:09:51 +0000 Received: from sirppi.helsinki.fi (localhost [127.0.0.1]) by sirppi.helsinki.fi (8.13.7/8.13.7) with ESMTP id n1KC9fWt043312; Fri, 20 Feb 2009 14:09:41 +0200 (EET) Received: (from jpihlaja@localhost) by sirppi.helsinki.fi (8.13.7/8.13.7/Submit) id n1KC9eLP046596; Fri, 20 Feb 2009 14:09:40 +0200 (EET) Date: Fri, 20 Feb 2009 12:10:00 -0000 From: M Joonas Pihlaja To: Brian Gough cc: gsl-discuss@sources.redhat.com Subject: Re: Conditional compilation based on GSL version In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q1/txt/msg00012.txt.bz2 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