Now that we have packages, they provide a natural boundary. The relative placement of files from different packages shouldn't matter, since packages don't have a fixed installation location relative to each other. So, I've changed `raco distribute` to preserve relative locations only among files from the same package.
At Wed, 30 Apr 2014 12:56:01 -0600, Matthew Flatt wrote: > At Wed, 30 Apr 2014 22:23:25 +0400, Dmitry Pavlov wrote: > > > Sometimes, that strategy ends up saving more information about the > > > source directories than you'd like to appear in an executable, such as > > > a user's directory name. We need some strategy to avoid that extra > > > information while preserving relative file locations when needed. > > > > Yes, I noticed that too. There is certainly no need to save the full > > directory structure (starting from C:\) to some "exts\\ert\\r0" > > directory. Some deeper common ancestor should suffice (is the > > directory structure needs to be saved at all)? > > In your example, the obstacle is that `raco dist` must include both > > C:\program files\racket\share\pkgs\srfi-lite-lib\srfi\29\bundles > > and > > C:\repo\era\rea\epm2004-booka\venus.rea > > in the distribution, and `raco dist` currently has no way of knowing > whether the relative path from "bundles" to "venus.rea" is significant. > For example, "bundles" might contain some non-Racket file with the > relative path > > ..\..\..\..\..\..\..\..\repo\era\rea\epm2004-booka\venus.rea > > where that relative path is expected to work after `raco dist` copies > everything into place for the distribution. > > Of course, "bundles" doesn't contain such a relative path. Possibly, > the fact that "bundles" is in the main installation and "venus.rea" > isn't should be a clue for `raco dist`. Or maybe relative locations of > runtime files should be assumed irrelevant unless a programmer > explicitly declares otherwise. ____________________ Racket Users list: http://lists.racket-lang.org/users
