[Asdf-devel] mkcl and asdf

[Robert P. Goldman]

Question of clarification: how does MKCL interact with the ASDF release process? 

MKCL will bundle a specially-tailored version of ASDF, is that right?

If so, there is no requirement that we wait for completion of the MKCL version before releasing ASDF 3.1, is there? What we want is just an ASDF that is a suitable candidate for bundling. Is that correct?

Sent from my iPad

> On Apr 16, 2014, at 12:44, Faré <fahree at gmail.com> wrote:
> 
> OK, here's a better patch for MKCL and ASDF.
> You were having ASDF re-load itself before it's configured;
> that's the recipe for loading the one that is in the user's normal
> configuration,
> environment variable or not.
> Later in the script, you correctly configure ASDF, and
> ASDF 3 does its own reloading automatically, so you don't need this step.
> Actually, if you're upgrading from ASDF2, you'll need more steps than that,
> before of the package punting; but you're not, are you?
> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> "Poetry is what gets lost in translation." — Robert Frost
> 
> 
> On Wed, Apr 9, 2014 at 8:36 AM, Faré <fahree at gmail.com> wrote:
>>>> 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?
>> grep 'getenv.*"' *p u*/*p actually finds 15 different variables that
>> *may* be used.
>> But when these two are controlled, all other variables are unused, except for
>> __CL_ARGV0 that you shouldn't care about and TMPDIR (or TEMP, on Windows)
>> that should be left in the user's control —
>> if it's bogus, a lot more things than ASDF will break;
>> and if the user wants to divert it, he probably knows what he's doing.
>> 
>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
>> Love doesn't scale. — Eric S. Raymond
> <0001-Don-t-re-load-asdf-before-you-configure-it-or-you-mi.patch>
> _______________________________________________
> Asdf-devel mailing list
> Asdf-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel