[Ecls-list] OpenAxiom and detecting ECL's ABI

[dherring at tentpost.com]

Hi all,

Wow.  I guess I'm glad I didn't check my email until lunch at work today. 
FWIW, I use both projects at home.  I skimmed the other thread, and my
reply will be brief.

Getting compatible CFLAGS and LDFLAGS is a hard problem, and it comes up
regularly.

A few approaches are common in this situation (numbered at random):
1) The library (ECL) provides a tool like pkg-config to retrieve flags.
2) The program (OpenAxiom) directly configures and compiles the library.
3) The program guesses flags based on known tokens (e.g. uname or
*features*) (FRAGILE!! see imake)
4) The program compiles and links test programs to see what works (e.g.
autoconf)

I have a preference for (4); at the end of the day, it is both flexible
and reliable.  However, it is often the most difficult to implement
(especially on MS-broken-windows).  As a middle ground, I often start
implementing (4) as a simple wrapper for the other methods, extending it
when problems are found.

Option (1) looks easy, and it can be required for some things.  (See
Autoconf notes on things that can't be detected automatically, or see the
recent Libtool thread on detecting /usr/local/lib vs /usr/local/lib64.) 
However, (1) fails when the program needs information not anticipated by
the library.  It also involves redundant information (a common source of
inconsistency).

Option (2) works nicely when you don't have to reuse system libraries. 
End users often think it is easy (since the program can include the
library in a single downloadable).

I sometimes wish *features* had been deprecated.  It can lead to a kludgey
coding style, is easily implemented in user space, and I've wanted to use
those macro characters a few times.  Implementations are often cavalier
about what they put on there, and code often infers much more than it
should.  Classic example: checking #+(or lisp-a lisp-b) to see if a
function is available, rather than directly checking for the function...

When the library maintainers are willing to work with the program
developers, it can often work to move the data from (4) into a format
accessible via (1).  Thus on autoconf platforms, CC, CFLAGS, etc. are
passed straight through; where the library uses other build systems (e.g.
wince), hard-coded settings are maintained with the build configuration.

That was less brief than I intended...

Later,
Daniel