Re: Could there be a way to disable LOAD-PREFERENCES?

Robert Goldman <[email protected]> writes:
> Richard M Kreuter wrote:

>> The problem I'm talking about above is that some .asd files contain
>> things like this
>> 
>>   (eval-when (:compile-toplevel :load-toplevel :execute)
>>     (asdf:operate 'asdf:load-op "some-asdf-extension"))
>> 
>> In these cases, the system being loaded by an inferior call to OPERATE
>> will receive only the initargs in the file.  These OPERATE calls are
>> not part of the planning done by TRAVERSE, but side effects of LOADing
>> .asd files.
>
> And this is necessary because one needs to have loaded the system in
> question (in your example "some-asdf-extension") in order to be able
> to even load the asd DEFINITION, not just to load the asdf system in
> question.

Right.

> Hm...  It's not even entirely clear to me what is the right thing in 
> this context.  If the other system is loaded in order to load the asdf 
> *definition*, rather than the asdf system itself, it seems entirely 
> appropriate to me that it would NOT inherit the initargs.  After all, if 
> one is going to :force recompilation of one's own system, that's not a 
> good reason to force recompilation of the ASDF infrastructure, as in 
> your example....

Drat.  I hadn't really thought about :FORCE.  Back to the drawing
board...

> I'm having a hard time seeing why this is a problem, since it seems like 
> either (a) the user would be configuring this system 
> (some-asdf-extension) him/herself, and would be quite capable of 
> ensuring it's loaded properly or (b) the user wouldn't know about 
> some-asdf-extension, so the user wouldn't have any local preferences 
> anyway....

Well, the the specific problem is that I want to be able disable
preference loading during SBCL's build process, and some of SBCL's
contrib modules are ASDF systems that load ASDF extensions in the .asd
file, and so keyword arguments to the OPERATE call that implicitly
loads the .asd won't be able to inhibit preference loading for these
ASDF extensions.

But preference loading isn't the only place where one might want "top
level" OPERATE arguments to be available to "inferior" calls: for
example, the :VERBOSE NIL argument is supposed to muffle output of
OPERATE, but it doesn't end up affecting inferior calls to OPERATE.
(This is why the only ASDF noise you normally see from REQUIRE in SBCL
is the message about loading sb-grovel, which is done in other
systems' .asd files.)  

So ISTM that something is missing "between" these calls to OPERATE,
but I don't know what.

--
Richard


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/