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

Richard M Kreuter wrote:
> 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.
> 
I hesitate to say this, but it seems like what is wanted here is less
argument/initarg propagation, and more like dynamic variable binding.

Best,
r

-------------------------------------------------------------------------
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/