On Tue, Apr 8, 2014 at 11:16 AM, Faré <fah...@gmail.com> wrote: > Right now, I have it busy-looping into plenty of > ;;; 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. > > I have to admit that interference from the process environment was not on my list of identified threats. I just committed two lines in my src/build-asdf-contrib.lsp to guard against that. I hope its enough. I looked into the source code of ASDF and saw that it read the content of at least 11 environment variables! Should I be paranoid and guard also against the 9 nine others beside the two you mentioned? > ... > >> 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? > > Please DO NOT try to include compatibility with older versions of MKCL before 1.1.9 since that aspect of them is simply a hopeless broken mess that I can only wish to forget quickly.
_______________________________________________ Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
