[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auto(conf|make) style questions
From: |
tomas |
Subject: |
Re: Auto(conf|make) style questions |
Date: |
Thu, 20 Mar 2003 11:48:25 +0100 |
User-agent: |
Mutt/1.3.28i |
On Wed, Mar 19, 2003 at 06:57:26PM +0100, Andreas Rottmann wrote:
> address@hidden 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