From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gsl-discuss-return-5631-listarch-gsl-discuss=sources.redhat.com@sourceware.org>
Received: (qmail 6105 invoked by alias); 19 Feb 2010 20:22:55 -0000
Received: (qmail 6095 invoked by uid 22791); 19 Feb 2010 20:22:54 -0000
X-SWARE-Spam-Status: No, hits=-1.7 required=5.0
	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Feb 2010 20:22:51 +0000
Date: Fri, 19 Feb 2010 20:22:00 -0000
Message-ID: <87vddtou22.wl%bjg@network-theory.co.uk>
From: Brian Gough <bjg@network-theory.co.uk>
To: Rhys Ulerich <rhys.ulerich@gmail.com>
Cc: jungman@lanl.gov,
	gsl-discuss mailing list <gsl-discuss@sourceware.org>,
	"Field G. Van Zee" <field@cs.utexas.edu>
Subject: Re: Feedback from GSL folks on libflame 4.0
In-Reply-To: <4a00655d1002181150j3975f69bk29084d5b50eeb974@mail.gmail.com>
References: <4a00655d1002171047t4e87fb85w88b609245e3f9a8e@mail.gmail.com>
	<4B7D90B5.4020707@cs.utexas.edu>
	<4a00655d1002181150j3975f69bk29084d5b50eeb974@mail.gmail.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Message-Mac: 2775c5b27506b76590ed324c928bdea0
Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gsl-discuss.sourceware.org>
List-Subscribe: <mailto:gsl-discuss-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gsl-discuss/>
List-Post: <mailto:gsl-discuss@sourceware.org>
List-Help: <mailto:gsl-discuss-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gsl-discuss-owner@sourceware.org
X-SW-Source: 2010-q1/txt/msg00035.txt.bz2

At Thu, 18 Feb 2010 13:50:44 -0600,
Rhys Ulerich wrote:
> I'm willing to take a stab at providing the necessary error handling
> underneath flame to make it play nice with GSL's error handling
> model.
>  The obvious choice is to adopt GSL's routines.  However, flame is
> LGPL and so adopting GSL's GPLed error handling directly is not an
> option.
> 
> Do you know of an LGPL project that you believe does a good job in
> this regard?

I think the amount of code is so small that the licensing shouldn't be
a concern here.  If anyone wants to use the error macro definitions or
error handler from GSL under the LGPL I am fine with that.

-- 
Brian Gough