At Tue, 21 May 2013 05:29:19 -0600, Jay McCarthy wrote: > If you have the source, then you need all the phase >= 1 dependencies, > but if you just have the binary then you only need the phase = 0 deps.
That's the right idea, but not precisely correct. If you `(require (for syntax ...))' a module, then the module is still needed at run time, because it might have a `(require (for-template ...))', and so on. A modules referenced though `lazy-require' in a `for-syntax' import, however, could conceivably be omitted. For example, a large part of the Typed Racket compiler might be omitted as a run-time dependency for a Typed Racket program. We're not quite to the place where that will work out well, but I think we'll get there. > Similarly, for building the documentation. That's really the big one in the short run, I think. It's difficult to have anything small and still have Racket-style documentation. At Tue, 21 May 2013 08:10:02 -0700, Eric Dobson wrote: > Why would you need to run raco setup if the source was already > precompiled? It's easy to underestimate the complexity of `raco setup'. Indeed, if every `raco setup' started from scratch, it would be pretty easy. Instead, `raco setup' has to perform an incremental computation based on an inferred set of filesystem changes, where the computation to incrementalize includes bytecode compilation, document rendering, document database cross-referencing, path adjustments, and more --- and it's all supposed to work in parallel, it's not supposed to leave things in a bad state if it gets interrupted, it should recover from most any state including bad states inadvertently created by novice programmers, it's supposed to support shared non-writable parts and user-specific writable parts, it's supposed to support PLTCOLLECTS and PLTCOMPILEDROOTS, and it's supposed to have a dozen other properties that I'm forgetting at the moment. To answer the specific question, one reason you need to run `raco setup' on a precompiled collection to fix up the documentation cross-reference database and references, get libraries and launchers in place, and perform whatever install-time actions the package wants. Yes, we can make `raco setup' work with packages that contain both source and binaries, and I guess I'll go work on that instead of other directions. _________________________ Racket Developers list: http://lists.racket-lang.org/dev