Re: Auto(conf|make) style questions

From: tomas@fabula.de
Cc: rm@fabula.de
Subject: Re: Auto(conf|make) style questions
Date: Thu, 20 Mar 2003 11:48:25 +0100	[thread overview]
Message-ID: <20030320104825.GA9415@www> (raw)
In-Reply-To: <878yvbi6ih.fsf@alice.rotty.yi.org>

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