The new function allows declaration of a module dependency, as
opposed to a mere file dependency. Misuse of this function opens
the door to cyclic compilation dependencies, so we have to check
for that in `compiler/cm'.
The new parameter (and supporting environment variables and
command-line flags) can bytecode lookup to a tree other than
where a source file resides, so that sources and generated
compiled files can be kept separate. It also supports storing
bytecode files in a version-specific location (either with
the source or elsewhere).
In particular, allow a pair of a relative-to directory and a base
directory. Paths that syntactically extend the base directory are
recorded as relative to the relative-to directory (which must
syntactically extend the base directory).
The compilation manager now sets the parameter to a pair with
the base directory as the main collection directory, if the source
file's path extends that directory's path.
This generalization solves problems created by cross-module inlining,
where the source location of a procedure in bytecode can now be in a
different file than the enclosing module's file.
Also add a test that checks whether the build directory shows up
in any ".zo", ".dep", or documentation ".html" files.
Closes PR 12549
managed-compile-zo
make-caching-managed-compile-zo
make-compilation-manager-load/use-compiled-handler
that gets used when compiled files, dep files, and compiled/ directories are created.
using a SHA1 hash stored in the marshaled bytecode; this cache
lowers the cost of sandboxes or other uses of multiple namespaces
when the code inspector doesn't change; the caching is almost
transparent, but an eval handler might be called with compiled
code that cannot be written
Reverts commit fe60da72c8.
Something about the recfatoring was broken. For example, modify
"racket/contract.rkt" and then run `raco setup -D -j 1 racket'.
Another `raco setup -D -j 1 racket' re-builds a file in
"mred", but a second run shouldn't have built anything. (Using
`-j 1' demonstrates that it's not related to parallel builds.)
Reverting the refactoring fixes the problem.
I don't know what the bug was, but Kevin says that the refactoring
wasn't needed after all.
--- a reversal of opinion from my earlier commit; the problem
with syntactic simplification is that it may not refer to the
same file, due to soft links; given that true normalization is
impossible, simplify-path and simple-form-path provide a good
compromise between preserving paths as given and exanding
soft links as neede
