[asdf-devel] optimization settings

[Robert Goldman]

Faré wrote:
> While developing XCVB, I was reminded that when you declaim or
> compile-toplevel proclaim optimization settings, these settings may
> (ccl, allegro) or may not (cmucl, sbcl) persist beyond the compilation
> of the current file. To make the build deterministic, XCVB now resets
> the settings before every operation. And then I remembered that in
> building QRes at ITA, I had similarly had to reset settings around
> every system if not every file, so that one library's preferred
> settings would not pollute the build of each and every other
> subsequent piece of compiled code.
> 
> The most directly relevant piece of code we use is as follows:
> 
> (defmethod asdf:perform :around ((op asdf:compile-op) (system asdf:system))
>   (with-local-compilation-settings ()
>     (proclaim-optimization-settings-for system)
>     (call-next-method)))
> 
> (defmethod asdf:perform :around ((op asdf:load-op) (system asdf:system))
>   (with-local-compilation-settings ()
>     (proclaim-optimization-settings-for system)
>     (call-next-method)))
> 
> I tend to think that this should be around every component on not just
> systems (and that's what XCVB does) but in the above modification I
> was conservative. Would you agree to include code to this effect in
> the upstream ASDF? Otherwise, the effects of proclaim and declaim
> beyond the current file become implementation-dependent and that
> sucks, and/or people have to use declare (maybe locally) instead,
> which also sucks.


I second this suggestion.  Just last week I found that suddenly
debugging failed to work, because my lisp implementation had lost all
its source code information.  It took me quite some time to track down
all the library dependencies, then grep over all of them for declaim and
proclaim with optimize, in order to fix this problem to which Fare
alludes above.

Best,
R