From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: tomas@fabula.de Newsgroups: gmane.lisp.guile.devel Subject: Re: Auto(conf|make) style questions Date: Thu, 20 Mar 2003 11:48:25 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <20030320104825.GA9415@www> References: <20030319172104.GA6109@www> <878yvbi6ih.fsf@alice.rotty.yi.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1048156104 21232 80.91.224.249 (20 Mar 2003 10:28:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2003 10:28:24 +0000 (UTC) Cc: rm@fabula.de Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 20 11:28:20 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18vxHY-0005Vq-00 for ; Thu, 20 Mar 2003 11:28:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18vxHM-0001gs-04 for guile-devel@m.gmane.org; Thu, 20 Mar 2003 05:28:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18vxGs-0000Z1-00 for guile-devel@gnu.org; Thu, 20 Mar 2003 05:27:38 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18vxGl-00009D-00 for guile-devel@gnu.org; Thu, 20 Mar 2003 05:27:34 -0500 Original-Received: from [217.22.192.104] (helo=www.elogos.de) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18vxGj-0008Tc-00 for guile-devel@gnu.org; Thu, 20 Mar 2003 05:27:29 -0500 Original-Received: by www.elogos.de (Postfix, from userid 5002) id 5A9D414080; Thu, 20 Mar 2003 11:48:26 +0100 (CET) Original-To: Andreas Rottmann Content-Disposition: inline In-Reply-To: <878yvbi6ih.fsf@alice.rotty.yi.org> User-Agent: Mutt/1.3.28i Original-cc: guile-devel@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2098 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2098 On Wed, Mar 19, 2003 at 06:57:26PM +0100, Andreas Rottmann wrote: > tomas@fabula.de writes: > > [not CCing autoconf, since this is not really AC-specific] > > > Hi, [...] Thanks, Andreas, Rob, Mikael and Alexandre for your comments. > It's certainly possible to do a feature test for each non-portable > function, but there is another way: Test for the guile version and use > a portability header + source file [...] See below. > BTW: It might be useful to have some coordinated work here and have a > tiny 'guile compatibilty project'. Definitely, and this was part of the purpose of my whining ;-) I'm having a look at your approach in Serveez and at Mikael's proposal in CVS Guile guile-core/examples/compat. Yes, I think this could ease transitions quite a bit, and allow people to `code towards future interfaces' instead of sticking to old ones for the sake of compatibility. As far as I see, we have several choices: Version test versus feature test: Each approach has its merits and disadvantages. As far as I understand, configury has a strong leaning towards feature test; i guess that it just scales better to many/big libs. I had a bias towards feature tests myself, but after reading Rob's and Andreas' posts I'm not so sure anymore (I have a high opinion of your taste in such things). Note that Mikael's proposal goes the ``feature test'' way. Version test: pros: - test is simpler: you just check for a version and take in an appropriate compat header/lib depending on the result. - test catches better `semantic' changes: the name/interface of a function doesn't change, but some subtle semantics in the implementation. cons: - it doesn't scale very well across many versions of a lib - it is a more brittle ``all-or-nothing'' approach (this may be seen as a restatement of the above). For feature test, just reverse/negate pros and cons. I'm trying to come up with something which can be used as a model for a compatibility project, as Andreas proposes. I'd love to have something more general, but a 1.6/1.7 transition help thing would be already great. What do you think? Regards -- tomas _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel