[plt-scheme] Disabling the compilation manager for system directories?

On Sat, May 3, 2008 at 11:56 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>  Is it a file-modification-date problem, a bug, or are installation
>  files somehow changed or redirected to depend on non-installation
>  files?

I enabled tracing in the compilation manager, and eventually puzzled
out what was happening.

* Bug #1 (in Halyard): Bad current-library-collection-paths

Our halyard/loader/collection-paths.ss had set up a bogus search path,
containing _both_ the system 'collects-dir, and another 'collects-dir
that was lying around. So PLT was getting terminally confused, and
trying to mix files from two different copies of swindle.

But how did we manage to get so confused? Further investigation revealed:

* Bug #2 (in MacPorts mzscheme): Bad 'collects-dir

Under MacPorts (and possibly other Unix-style package managers), the
value of (find-system-path 'collects-dir) doesn't get set up
correctly.  But on those systems, we can generally find our
collections in the appropriate directory under (find-system-path
'addon-dir).

Normally, we don't notice the bogus collects-dir, because
(find-library-collection-paths) also looks in addon-dir.  This makes
ordinary (require (libs ... "mzlib")) forms work correctly.

But the compilation manager relies on things like
(main-collects-relative->path '(collects . #"swindle/turbo.ss"))
resolving to actual collection paths.  And this will only work if
(find-system-path 'collects-dir) returns something reasonable.

We worked around this by adding 'addon-dir to the list of places we
look for the system collections:

http://iml.dartmouth.edu/git?p=halyard.git;a=commitdiff;h=f9b049bc4362426ca9314986e32fb3e50d7fe4e4

As a nice side-effect, this allows us to enable to enable the
compilation manager on the Mac version of Halyard, speeding up reloads
by a factor of 5 to 10.

Once again, thank you for your help!

Cheers,
Eric

http://iml.dartmouth.edu/halyard/