[Ecls-list] Help needed, really

[Matthew Mondor]

On Sun, 2 Jan 2011 23:53:39 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> I started precisely the ECL project because I was not able to build some
> software on my system and I was not clever enough to fill a configuration
> file, and much less learn the innards of the OS I was using. I shied away
> always from the philosophy of knowing all the platforms where my programs
> should work and their inner details and stick to POSIX, C, C99 or whatever
> standards were available, avoiding complications of binary formats, loaders,
> linkers and the like. Because I know my limitations, and because I know that
> there are people who do this (systems programming, garbage collectors,
> knowing a lot of OS details and the like) much better than me. Well, maybe
> after all I am not suited for the job.

I personally like ECL for what it does, and also because of the way it
works.  I am sure that most other regular ECL users also see its value,
and know that without your efforts ECL would not have become what it is.

I do not see this issue as one which should question your competency;
it is indeed a non-trivial problem considering the design of ECL (and
moreover, the lack of a standard way to represent these among the
various Lisp implementations, C compilers and tools like file(1)).

I personally think that if it matters that much for a project, it could
build ECL itself (that doesn't mean that it must include the ECL
source, though, BTW), which is also compatible with "embeddable" usage
to me.  For instance, if the host C (for ECL, GMP, GC) and C++ (for
OpenAxiom) compilers are used together with the same flags, they should
most probably be compatible, just like GTKmm (C++) must be
link-compatible with the GTK library (C) on the same host, and the
package managers for an OS/project pair are generally the ones taking
care of this.

Moreover, ecl-config does provide the necessary CFLAGS and LDFLAGS for
a C-style environment to use (and those may include any flags the
package maintainer wanted to use).  As for the CL side, ECL also does
provide the necessary standard constants for portable CL code to use,
as well as support for dffi and a powerful custom FFI system.

Therefore, I expect code needing any additional information to need to
either requestion their design or find out that information themselves
using heuristics available at their disposition for their non-standard
requirements...  and that may include autoconf hints and/or compiling a
fasl to then analyse its properties, or even small test
C/C++/CL+FFI/CFFI-grovelling programs making use of arithmetic and the
like for what they really need to know on the limited environments they
intend to support (because code that aims to be more portable will
generally trust the CL and underlaying C environment in this case,
leveraging ECL's strengths).  Of course, that is only my opinion,
though.
-- 
Matt