If a Mach-O file installed with `{copy,move}-foreign-libs` has a
"@loader_path/" reference to a library that is installed in a
different target directory (normally because it's from a package that
is installed in a different scope), then change "@loader_path/" to an
absolute-path reference to that target.
The `panel%` and `pane%` classes were not originally intended for
direct instantiation; instead, `horizontal-pane[l]%` and
`vertical-pane[l]%` provide basic placements that make sense for
multiple children. Adjusting `pane[l]%` to just overlay all children
seems both sensible and useful (if only one child is shown at a time,
for example).
As suggested by David Nelson.
Currently the optimizer can convert ((let (...) ... proc) x) to
(let (...) ... (proc x)). This is useful especially if proc can be
inlined. Extend this to begin's forms.
Previously, the optimizer simplified the application of some unary functions inside let,
for example (car (let () ... (cons 1 2)) => (let () ... 1). This commit extends this to begin forms,
like (car (begin ... (cons 1 2)) => (begin ... 1).
Also, constant folding and some reductions were only availed in the direct case, for example
(procedure? car) => #t. With this commit these reductions are extended to the expressions
inside let and begin, for example (procedure? (let () (begin ... car))) => (let () (begin ... #t).
got broken in 2e284cc783
The racket version of libunwind is not compatible with QNX but old-style stacktraces are still working with the default gcc version
If "p" is available as a source package, which is typical, then `raco
pkg install --binary p` would strip away the build dependencies of "p",
so that "p" would not install properly.
This commit changes `raco pkg install` to look for an annotation on
the package and complain if the annotation is inconsistent with the
requested conversion: a binary package cannot be used as a source
package or vice versa. (A built package, as provided by a snapshot
site, can be used as any kind of package.)
The `--binary-lib` mode is like `--binary`, but it also omits
documentation to form a "binary library package".
The `--binary-lib` flag and "X-lib" vs. "X-doc" approaches solve the
same problem with different trade-offs:
* When a package is split into "-lib" and "-doc" packages, then it's
easier install non-documentation parts, and it's possible to
install them from source. A programmer has to work more to split
the packages, however, and the library and its implementation must
have separate sources (i.e., no or restricted in-source
documentation).
* When a package is just "X", then users can install a no-source,
no-documentation version by specifying `--binary-lib`, but only
when the package is available from some catalog and provider in
built form (such as from a distribution site or a package-build
service).
In the long run, I think that relying on `--binary-lib will be best
and typical for most packages. The "X-lib" plus "X-doc" approach
that's common in the current distribution's packages, meanwhile, will
likely stick around for basic packages that are commonly useful in
constrained settings (including the setting of a package-build
service).
The `update-implies` declaration is half of `implies` (even though the
name is bigger): update of the package implies an update of another,
but a dependency on the package is no license to access the content
of the other.
This declaration is intended as an alternative to keeping version and
dependency declarations in sync for a pair of packages that are always
updated together, normally because the packages are in the same
repository. For example, a "-test" or "-doc" package might have an
`update-implies` declartion on the corresponding "-lib" package.
Adjust dependency tracking and makefile rules to that when
`--enable-racket=...` is provided to `configure`, intermediate
CGC objects are not compiled.
The new approach uses dependency tracking that was already supported
by xform, previously used only for Windows.
Although newer versions of Visual Studio can open 2010 projects, the
meaning of the project turns out to be: use 2010 tools. So, I've added
a step in the build script to automatically upgrade the solutions and
projects based on the version of Visual Studio that is being run.
Meanwhile, since my previous tests for VS 2012 and VS 2013 were using
VS 2010 projects, I wasn't actually testing with the 2012 and 2013
compilers. Additional changes are needed to make those work, notably a
fresh implementation of setjmp() and longjmp() for Win64.
This was all very painful, but the projects are now in much better
shape, so maybe it won't be so bad from here.
