On installation issues:
1) Yes on defaulting to an installation-wide install as default.
2) A non-UI build installation, "server" build capability (in a
backend/engine/runtime not web sense), Image manipulation libraries etc are
installed but full DrDr and associated tooling is not. (e.g. fast build on
a "cloud" server straight from git with minimal core collection/library
support).
- Building Racket from source on a AWS small 64-bit server fails. It
shouldn't (last time I tried) and it is a niggling inconvenience that it
is so.
3) Many (even most) of the collections library are non-core and IMHO
should be evicted out into separate github hosted projects with drop-dead
simple installation via Planet2 on demand. I know this sounds harsh, but
collects is over due for a healthy paring, if not a full blown gastric
by-pass.
- I think an independence of development/release cycles between Racket
and a host of stuff in collections is healthier for Racket and those
libraries as well.
Ray
On Sat, Jan 5, 2013 at 9:58 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> I have been thinking about how developers who build their own Racket
> are more likely to want installation-wide packages instead of user- and
> version-specific packages. This is particularly true for those of us
> who work from the git respository.
>
> Maybe the default for a build `configure'd without `--prefix' (or, more
> generally, for a non-Unix-style build) should be installation-wide
> package installs, while the default for our pre-built distributions
> should be user- and version-specific installs.
>
> The default mode would be determined by configuration information in
> the installation-specific package area, and something like `raco pkg
> config -i default-mode <mode>' could change an installation's default.
>
> Does this sound like a good idea?
>
> _________________________
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
