: Faré
: JCB
: JCB
I managed to compile MKCL from git, but only after I updated its ASDF.
I just did the following sequence on a fresh Ubuntu 13.10 x86 with proper tools and libs installed without any incident:
git clone git://common-lisp.net/projects/mkcl/mkcl.git cd mkcl ./configure make all sudo make install
So I don't see what your problem could have been. Could you cut and paste the exact error messages you received.
Right now, I have it busy-looping into plenty of ;;; Loading "/home/tunes/src/mkcl/contrib/alexandria_2012_08_14/alexandria.asd"
the last messages before that are: ;;; Loading "asdf.fasb" ;;; Loading "/home/tunes/cl/asdf/asdf.asd" ;;; Loading "/home/tunes/cl/asdf/uiop/uiop.asd" ;;; Loading "/home/tunes/.cache/common-lisp/mkcl-1.1.9-linux-x64/home/tunes/cl/asdf/build/asdf.fas" ; Upgrading ASDF from version 3.0.3.0.1 to version 3.1.0.111 ;;; Warning: The following packages were referenced in compiled file (/home/tunes/cl/asdf/build/asdf.lisp) but d o not exist yet: (ASDF/PARSE-DEFSYSTEM). ;;; Warning: The following packages were referenced in compiled file (NIL) but do not exist yet: (ASDF/PARSE-DEF SYSTEM). ;;; Loading "/home/tunes/src/mkcl/contrib/alexandria_2012_08_14/alexandria.asd"
This suggests that one of the things you need to do is have tighter control over the CL_SOURCE_REGISTRY and ASDF_OUTPUT_TRANSLATIONS around this compilation, to prevent the unwanted ASDF upgrade.
On the other hand, this suggests a bug in ASDF itself and how it upgrades, that I need to investigate. Sigh.
Unless you have a good reason, I recommend you only include a bootstrapped version of asdf.lisp in your source tree. You should of course keep generating it from an asdf checkout, and send us any local patch you create (thanks a lot for that!)
I am building a separate uiop module out of that set of sources so that part would have to stay anyway. File asdf.lisp is not an original source file but a derived one, concatenated from the real original source files kept in the asdf directory, as you well know, so it is not really a proper base for the build process. Further I do not see any real and concrete inconvenience to the current layout of things in contrib/asdf. To the contrary, I find it very convenient when I need to diff against a more current asdf git clone or tarball.
Oh, that's great — and I commend your attention to detail. Another option you might consider is a git module, but I understand it's heavier weight.
In 3.1.0.109, I have an attempt at implementing get-optimization-settings on most implementations (allegro is still missing, plus ecl-bytecmp, genera, corman, mcl); my implementation for MKCL does not work and/or proclaim does not work: c::*speed* exists but isn't updated by proclaim. Can you help me fix that?
I will back port to MKCL 1.1.9 the fixes I currently have in MKCL 1.2.0. You will have them in the git repository in a few hours. compiler::*speed* is going away anyway since proclaim at al. need to work even when the "CMP" module has not been loaded, use si::*speed* instead. Also, nickname "C" for package "COMPILER" has been removed since MKCL 1.1.0 at least (too clash prone).
I will back port to MKCL 1.1.9 the fixes I currently have in MKCL 1.2.0. You will have them in the git repository in a few hours. compiler::*speed* is going away anyway since proclaim at al. need to work even when the "CMP" module has not been loaded, use si::*speed* instead. Also, nickname "C" for package "COMPILER" has been removed since MKCL 1.1.0 at least (too clash prone).
Done and pushed to the git repo. So you now have si::*speed*, si::*safety*, si::*space*, si::*debug* and si::*compilation-speed* that store the global level environment for "optimize", each with integer values between 0 and 3 inclusively by convention. Crude but does the job...
Great. Is it OK if I don't include compatibility with older versions of MKCL?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Tomorrow, I stop procrastinating.