[Ecls-list] cl-launch and ECL

[Faré]

Dear ECL hackers,

I realize I hadn't properly tested image dumping with ECL, and that I
didn't get it to work properly in presence of systems. The issue is
manyfold:

(1) ECL's compile-file-pathname is broken (see previous file). I could
work around that by wrapping a fix.

(2) c::builder is broken by forcing :type "o" on all the specified
:lisp-files. This is quite a problem when some of the files are
library files created by a previous run of the builder. [I could
possibly work around by renaming files but it's getting ugly.]

(3) the builder insists on using -l flags to specify a library for
each asdf system being depended upon. Instead, cl-launch needs to be
able to compile library dependencies for asdf systems on-demand into
its compilation cache and to specify an explicit path to the libfoo.a
for each of these libraries the final compilation -- OR it would be
nice if c::builder had a flag whereby it would use asdf:output-files
for each of the libraries and either trust the result as the library
to load, or probe-file the library and only fallback to using -l if it
is not present. OR, you shall let me specify paths where to look for
libraries (but what if there are name conflicts? I'd rather specify
the full path for each of the things I want).

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote." -- Benjamin Franklin, 1759


On 10/08/06, Faré <fahree at gmail.com> wrote:
> Dear ECL hackers,
>
> I got cl-launch to kluge around these pathname bugs in
> compile-file-pathname and c::builder by explicitly wrapping calls to
> compile-file-pathname around something that systematically uses the .o
> suffix when system-p is used (to reflect what c::builder expects), and
> calls to c::builder with something that renames the output file if it
> differs from what is desired (e.g. does not end in .fas).
>
> I'm proud to announce cl-launch 1.84 as fully supporting ECL, despite
> these minor bugs in ECL.
>
>    http://cliki.net/cl-launch
>    http://fare.tunes.org/files/cl-launch/
>
>
> Please fix the bugs so I can clean up the kluges in cl-launch:
> (1) c::builder has to accept arbitrary names and not overwrite their
> suffix. If the C compiler requires pathnames to have a type that
> matches the type of their contents, then either c::builder should
> throw an error when given wrong names (and document the fact), or it
> should do the right thing through renaming, copying or linking to a
> temporary file; same thing with the output.
> (2) as per CLHS, compile-file-pathname should accept the very same
> lambda-list as compile-file and vice-versa, whatever these arguments
> are. This means supporting system-p in the lambda-list as well as all
> other compile-file flags. That also means correctly supporting
> output-file in the lambda-list, to prevent the same bug as fixed in
> SBCL recently.
> (3) if c::builder requires suffixes to match as opposed to doing
> renamings, compile-file-pathname should do the right thing, i.e.
> provide a correct suffix by default, and either force that suffix
> (through merge-pathnames) or throw an error if a different suffix was
> provided through :output-file.
>
> PS: the debian package also has to be fixed to use the ECL version of
> asdf and not loading the compiler with *load-verbose* t. -- Meanwhile
> debian cl-launch users have to export ECL=/usr/lib/ecl/ecl-original
>
> Thanks a lot for this fine piece of software!
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> The older I grow, the more I distrust the familiar doctrine that age
> brings wisdom.
>                 -- H.L. Mencken