Re: [Gcl-devel] C library support [ was Re: BLAS and GCL ]

[Michael Koehne]

Moin Camm Maguire,

> 1) read the piped output of 'nm' or 'nm --dynamic' on the library and
>    collect the exported symbols

  the problem here, is that nm could only tell about function names,
  but not about their arguments. One has to parse include files here.

  My approach was to parse them into a normal assoc to a list. This
  avoided building mega-lisp-cores including the complete linking for
  X+GL+GLU. I could pick them on demand, to build some gazonk, to
  include a much smaller core, including only the interfaces I need.

> 2) make a readtable which can parse the header file to read the
>    prototypes.  Paul do you know of such a parser already available?

  *blush* I've used a perl parser, instead of a readtable ;( I've
  browsed the web - found none at a first glance, but think that
  using a readtable would be nice idea ;)

> The biggest complaint about lisp is the (lack of) library support, and
> the idea of reimplementing everything in lisp appears to me to be a
> definite non-starter.  Were such a modular approach to external C libs
> attainable, one could dispense with separate support for xgcl, pargcl,
> etc. and greatly simplify future maintenance.

  it would be nice, if those gcl-boosters would build after a basic
  ansi-gcl was installed. This basic-ansi gcl wont need any readline,
  X interface, Tk interface, ... - as one could just build his own
  lisp including those, on demand. I dont know if ASDF is the right
  track as it does not yet work for GCL. Perhaps a simpler defsystem
  approach would enable us to unbundle those libs from basic ansi-gcl
  in 2.8.x ;)

Bye Michael
-- 
  mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM