[Ecls-list] Help needed, really

[Samium Gromoff]

On Sat, 1 Jan 2011 15:30:18 +0100, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:
> What I meant is the following: ECL does not gather specific information
> about processor types and how they are used. Instead there are checks for C
> types, sizes and precisions , some of which are performed during the
> "autoconf" phase, some others when ECL is compiled. This information is
> available at runtime via the FFI package, size-of function and multiple
> constants (c-uint-max, etc).
> 
> Is this enough?
> 
> It depends. OpenAxiom contains a mixture of C++ and lisp code and decides
> how to compile the former based on the later. It does so using specific
> information about the system that the lisp implementation provides:
> processor type and ABI type (64-bit or 32-bit) It is assumed that the
> implementation must provide this because it is a compiler, even if we do not
> directly use that.
> 
> Problem is I do not really know how to provide this in a way which is both
> portable and future proof.
> 
> Autoconf tests are known to be broken, as processor names do not work on
> various platforms. THe notion of 64-bit or 32-bit is ambiguous unless we
> restrict ourselves to "pointer sizes" and in that case it is provided by ECL
> in the FFI. But I presume that what is being asked for is what DS mentioned
> about specific ABI names, but that means adding extra logic to autoconf,
> something which I do not know how to maintain -- and do not have the time
> to.

I think I have a solution, with the following properties:

  - it offloads the maintenance off Juanjo, and to the interested parties,
  - it lets the interested party use a semi-standard approach, because
  - it is based on an already existing solution, and so
  - it promotes collaboration and furthers the CL platform as a whole.

The solution is simple: let the OpenAxiom authors, as seemingly the most
picky about these arch/cpu/binary flags, take over maintenance of
TRIVIAL-FEATURES, and depend OpenAxion upon it.

How exactly TRIVIAL-FEATURES achieves its goal currently (i.e. providing
a standartised set of platform-describing *FEATURES*) is not important,
what is important how it /should/ work.

So, /what/ should it do?

As already said, for full native compilers (SBCL, CCL etc), the full
information is already available, by the virtue of them bearing the
totality of the burden of compilation, and all *T-F* does is translating
implementation-specific platform descriptor symbols into standartised
platform descriptor symbols.

For ECL, though, the job of *T-F* would be to collect the basic
information exported by ECL and /deduce/ the final flags.

What this translates to, is that the ECL piece of *T-F* will have that
non-trivial logic necessary to assemble the required /final platform
information/ from /basic raw info/ provided by ECL.

So, there, my asbestos underpants are on, I'm ready for the flames : -)

-- 
regards,
  Samium Gromoff
--
"Actually I made up the term 'object-oriented', and I can tell you I
did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)