[Openmcl-devel] Re: building MCL for idiots (fwd)

Gregory Wright gwright at comcast.net
Thu Feb 26 22:34:28 UTC 2004


Hi,

OpenMCL under the darwinports infrastructure builds from source. The
standard build uses the tarballs for 0.14.1-pl1, but you can easily 
modify
it to download from cvs, if you want to live on bleeding edge.

General info is available at http://darwinports.opendarwin.org.

You can look at the openmcl portfile (a kind of meta-makefile) at

http://openmcl.darwinports.com

(When I last checked, the above page--not officially affliated with 
darwinports--
was out of date. It showed version 0.13.7. But you'll get the idea.)

HTH,
Greg


On Feb 26, 2004, at 5:11 PM, Gary Byers wrote:

> Cyrus Harmon said that it'd be OK to forward this message to this list;
> that might be more helpful than me saying "what do you mean ?  the
> documentation's perfectly clear ...".
>
>
> ---------- Forwarded message ----------
> Date: Thu, 26 Feb 2004 13:51:35 -0800
> From: Cyrus Harmon <cyrus at bobobeach.com>
> To: Gary Byers <gb at clozure.com>
> Subject: Re: building MCL for idiots
>
> That would be fine. Alternatively, I'm happy to join and post it
> myself, if you would prefer. I wasn't sure what the right forum was and
> didn't want to look like an idiot in front of too large of an audience.
>
> Thanks,
>
> Cyrus
>
> On Feb 26, 2004, at 1:43 PM, Gary Byers wrote:
>
>> Do you mind if I forward your message to the mailing list
>> (openmcl-devel) ?
>>
>> I think of the build process as being simple and clear, but I'm not
>> exactly
>> a neutral observer; some other people may have comments that'd be
>> helpful
>> to both of us.
>>
>>
>> On Thu, 26 Feb 2004, Cyrus Harmon wrote:
>>
>>>
>>> Well, maybe not idiots, but you get the point... Sorry for what I'm
>>> sure is a VFAQ, but is there any way to make the build process less
>>> painful for those that aren't intimately involved in the development
>>> efforts (and perhaps them too)?
>>>
>>> If I had my druthters, I'd do a cvs checkout ; make ; make install 
>>> and
>>> be off to the races. I understand that there are some problems with
>>> this with OpenMCL, but I still get lost every time I try to build the
>>> latest version. The html pages say that building from source is
>>> "preferable" and I tend to agree, yet I have a hard time getting all
>>> the various pieces (the lisp kernel, the lisp image, the interface
>>> database, etc...) to build properly and in the right order. This is
>>> confounded by the temporary cvs, the existence of different versions,
>>> etc...
>>>
>>> It's hard to know whether or not you're up to date on all of the
>>> various pieces. After poking around for quite a while, getting a new
>>> lisp kernel built, getting the interface database from 1.14p1, I get
>>> the following:
>>>
>>> ? (ccl:xload-level-0)
>>> Can't find #4P"ccl:xdump;xppcfasload.dfsl" so requiring
>>> "ccl:xdump;xppcfasload.lisp" instead
>>> Can't find #4P"ccl:xdump;xfasload.dfsl" so requiring
>>> "ccl:xdump;xfasload.lisp" instead
>>> Can't find #4P"ccl:xdump;heap-image.dfsl" so requiring
>>> "ccl:xdump;heap-image.lisp" instead
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-cfm-support.lisp"...
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-clos.lisp"...
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-complex.lisp"...
>>> ;Compiler warnings for
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-complex.lisp" :
>>> ;   Undefined function %IMAGPART, in COERCE-TO-COMPLEX-TYPE.
>>> ;   Undefined function %REALPART, in COERCE-TO-COMPLEX-TYPE.
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-dcode.lisp"...
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-debug.lisp"...
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-def.lisp"...
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-error.lisp"...
>>> ;Compiling
>>> "/Users/sly/src/openmcl/ccl-0.14/ccl/level-0/l0-float.lisp"...
>>>> Error in process listener(1): While compiling %SHORT-FLOAT-RATIO :
>>>>                               #1=(FNUM NUM) is not a symbol or 
>>>> lambda
>>> expression in the form (#1# (FDEN DEN)) .
>>>
>>>
>>> Maybe I need h-to-ffi.sh, but the instructions for that don't sound
>>> too
>>> pleasant either.
>>>
>>> Is there any hope of cleaning some of this stuff up and/or 
>>> simplifying
>>> the process and associated documentation?
>>>
>>> Thank you very much,
>>>
>>> Cyrus Harmon
>>>
>>>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>




More information about the Openmcl-devel mailing list