The `setup/winstrip` step was run too late. As an extra measure,
make make `setup/winstrip` more precise about the files it
will discard.
Merge to v6.3
Building creates compiler-specific files in "lib/msvc"
or "lib/gcc". For consistency, strip those directories
when creating a distribution.
The newly added ".def" file provides information that
would otherwise be lost by removing the MSVC ".lib"
file from the distribution.
Removing the compiler-specific ".obj" files means that
used to be included for linking extensions. My guess
is that the files are now completely unused.
The `as-is` target is like the default target, but it skips package
update and installation, so it's suitable for rebuilding after local
changes that might include changes to the core.
Restore (but in a hopefully better way) a step that installs native
libraries before trying a full `raco setup`, since the libraries
may be needed for the setup proces --- especially on Windows.
The source to the split packages is in repositories under the
`racket` organization on GitHub. The repositories are all named
according to the pkg name, except for multiple-package
repositories such as `racket/compiler` which is named based on the
old directory name without the `-pkgs` suffix. Thus
`pkgs/compiler-pkgs` -> https://github.com/racket/compiler
The Makefile has also been adjusted to pull packages from the
catalog when you type `make`. This currently relies on some tricks
that will break if you try to specify a particular set of `PKGS` on
the command line. We plan to improve this soon.
The packages in `pkgs/racket-pkgs` and `pkgs/base` are staying in
the repository, since they logically belong with the core code.
The `plt-services` package is still in the repository, but will
move out soon.
Mostly upgrades the drawing stack to the latest Cairo, Pango, Glib,
etc., but also upgrades the OpenSSL library on Windows to 1.0.1g.
The new "racket/src/native-libs" directory provides scripts to
rebuild the libraries from source. Those script are fragile, because
library sources and configuration scripts are fragile. The
scripts at least archive some expertise/advice in a mostly executable
form.
When the server installs packages from source, it needs configuration
entry that points documentation indirections to the right place.
A relevant "config.rktd" is written, but to the wrong place, so
that it wasn't being used.
Merge to v6.0 (pending review)
This change should fix a problem with the Mac OS X PPC build,
where the "libsqlite3" shared library needs to be installed
early. The same strategy is already used for Windows.
Merge to v6.0
The ".pkg"-based installer doesn't provide the option of picking
an installation path, but it can add a path in "/etc/paths.d"
so that users do not have to explicitly set the `PATH` environment
variable.
Downloaded files are keyed on the source URL and checksum, and the
cache is used only when a checksum is known.
The cache addresses two situations:
* when installing many packages over an unreliable connection,
the cache effectively lets a retry pick up where a previous
attempt failed
* when creating clean builds frequently, the downloads from a
previous build can be reused (as long as the package's checksum
does not change)
The cache location and limits are configurable, and they default to
a subdirectory in the user's add-ons directory (not version-specific),
1024 files, and 64 MB.
If a failure happens during staging (checksum and unpackaging) of a
package that has an entry in the cache, the entry is removed. The
file-cache library, meanwhile, implements a limit on the cache size
and defends against uncooperative filesystems.
This makes the build more secure, but it's a backward-incompatible change.
To adapt old site-configuration scripts, the simplest option is to set
`#:server' to "localhost" everywhere and rely on SSH tunneling to let
a client reach a server (though, unfortunately, that option doesn't
seem to work if a Windows machine uses freeSSHd). Another possibility
is to se `#:server-hosts' to the empty list.
Client SSH connections now create remote port forwarding port back
to the server, so that making the server listen only on "localhost"
provides an easy improvement for security (except that remote port
forwarding seems not to work with freeSSHd on Windows).
