[racket] Compiling A Collection - Module Resolving Blame

From: Ray Racine (ray.racine at gmail.com)
Date: Tue May 28 12:15:48 EDT 2013

I've created a mini-collection out on Github.

Consider the single collection, c1, with 4 modules.

m1.rkt -> m1a.rkt -> m1aa.rkt

Where m1 depends on m1a, m1a on m1aa and m2 had no dependencies.

--> raco link /code/tlib/c1
--> raco link -l
User links:
 collection: "c1"  path: "/code/tlib/c1"
Installation links:

--> raco setup c1

Completes without error.

Now imagine one performs some amount of intra-collection module
refactoring, module renamings, splitting and combing modules etc.

We simulate this activity with a single modification to the require in
m1.rkt to a now non-existent module.

 (only-in "m1a.rkt"

;; to

 (only-in "m1x.rkt"

Build the refactored collection.

--> raco setup c1
raco setup: version: [3m]
raco setup: variants: 3m
raco setup: main collects: /usr/local/racket/collects
raco setup: collects paths:
raco setup:   /home/ray/.racket/
raco setup:   /usr/local/racket/collects
raco setup: --- pre-installing collections ---
raco setup: --- installing foreign libraries ---
raco setup: --- compiling collections ---
raco setup: --- parallel build using 8 processes ---
raco setup: 7 making: /code/tlib/c1
default-load-handler: cannot open module file
  module path: #<path:/code/tlib/c1/m1x.rkt>
  path: /code/tlib/c1/m1x.rkt
  system error: No such file or directory; errno=2
   /usr/local/racket/collects/compiler/cm.rkt:372:0: compile-zo*
   /usr/local/racket/collects/compiler/cm.rkt:537:0: maybe-compile-zo
   /usr/local/racket/collects/compiler/cm.rkt:650:2: do-check
   /usr/local/racket/collects/setup/parallel-do.rkt:420:20: loop

raco setup: --- updating info-domain tables ---
raco setup: --- creating launchers ---
raco setup: --- installing man pages ---
raco setup: --- building documentation ---
raco setup: --- installing collections ---
raco setup: --- post-installing collections ---
raco setup:
raco setup: error: during making for /code/tlib/c1
raco setup:   default-load-handler: cannot open module file
raco setup:     module path: #<path:/code/tlib/c1/m1x.rkt>
raco setup:     path: /code/tlib/c1/m1x.rkt
raco setup:     system error: No such file or directory; errno=2
raco setup:     context...:
raco setup:      standard-module-name-resolver
raco setup:
/usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import
raco setup:      /usr/local/racket/collects/racket/private/reqprov.rkt:375:5
raco setup:
/usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import
raco setup:      try-next
raco setup:      /usr/local/racket/collects/racket/private/reqprov.rkt:242:2
raco setup:      success
raco setup:
raco setup:      /usr/local/racket/collects/compiler/cm.rkt:372:0:
raco setup:      /usr/local/racket/collects/compiler/cm.rkt:579:26
raco setup:      /usr/local/racket/collects/compiler/cm.rkt:572:42
raco setup:      /usr/local/racket/collects/compiler/cm.rkt:537:0:
raco setup:      /usr/local/racket/collects/compiler/cm.rkt:650:2: do-check
raco setup:      /usr/local/racket/collects/compiler/cm.rkt:731:4
raco setup:      /usr/local/racket/collects/setup/parallel-do.rkt:420:20:
raco setup:

Assuming co-occurrence of output happens across an N processor raco build,
we know that during the making of collection c1, module m1x was not found.

making: /code/tlib/c1
default-load-handler: cannot open module file
  module path: #<path:/code/tlib/c1/m1x.rkt>
  path: /code/tlib/c1/m1x.rkt

The critical information of whom to blame is missing.  In this case, the
culprit is m1.rkt, line xxx with a bogus require.

With a collection of a hundred module files or so, combined with multiple
issues from the refactoring, one is in for an afternoon of recursive
grepping etc.


1) Is this currently a "deep" issue, in the sense of how module resolving
and instantiation is performed, layered with Typed Racket's mode of
implementation, layered with CM and Raco's build system that prevents a
more informative error message?


2) Is this just a simple a bug, in the sense of oops, just forgot to print
the error message concerning the offending source module and line?

If its 2) I'll work on debugging for a fix.  If 1) I'm just not going to be
able to tunnel through raco -> cm -> tr -> module expansion to run this
down, so I'll punt.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130528/64dd26c6/attachment.html>

Posted on the users mailing list.