What about ./configure --enable-racket=`which racket` ?
Already needed and used for cross-compilation.
Tobias
On Tue, 12 Aug 2014 18:00:21 +0200, Matthew Flatt mfl...@cs.utah.edu
wrote:
I'm not sure how difficult it will be. It's tedious enough that the
last time I thought about it, I
Good point!
I assumed (based on earlier conversations?) that Sam knows about
`--enable-racket=...`. I thought that he was commenting on how the
build process would create things that are needed only for `racketcgc`,
even when `racketcgc` itself isn't needed.
I've now pushed changes that should
Apparently, when gcc 4.9.1 sees
memcpy(x, y, n);
if (y)
then it believes `y` can be assumed to be NULL --- even if `n` turns
out to be zero --- and so the conditional can be optimized away.
I'm surprised by that rule, but it's easy enough to move the test
before the memcpy().
At Tue,
The gcc 4.9 release notes warn about this optimization:
https://gcc.gnu.org/gcc-4.9/porting_to.html
I'm surprised that this change hasn't caused more trouble for us.
At Tue, 12 Aug 2014 08:39:01 +0100, Matthew Flatt wrote:
Apparently, when gcc 4.9.1 sees
memcpy(x, y, n);
if (y)
How difficult would it be to allow the bootstrap process to use a
preexisting Racket installation? This would alleviate some of the
performance loss, for example in rebuilds by developers or in continuous
integration.
Sam
On Aug 11, 2014 11:16 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I've
I'm not sure how difficult it will be. It's tedious enough that the
last time I thought about it, I just left a note next to
no-cgc-needed in racket/src/racket/Makefile.in, but maybe it's
worth pursuing now.
At Tue, 12 Aug 2014 04:39:55 -0700, Sam Tobin-Hochstadt wrote:
How difficult would it be
I've changed the Racket CGC implementation --- which is mostly used
only to build the normal Racket variant --- to use SGC by default,
instead of the Boehm GC. The intent of the switch is to make the more
portable GC the default.
If you have an existing build in a repo checkout, then `make` is
On 2014-08-12 05:16:21 +0100, Matthew Flatt wrote:
If you have an existing build in a repo checkout, then `make` is likely
to fail, because the makefile dependencies are not precise enough to
deal with the switch. You can discard your old build directory, or it
might work to simply delete
At Tue, 12 Aug 2014 00:43:04 -0400, Asumu Takikawa wrote:
On 2014-08-12 05:16:21 +0100, Matthew Flatt wrote:
If you have an existing build in a repo checkout, then `make` is likely
to fail, because the makefile dependencies are not precise enough to
deal with the switch. You can discard
9 matches
Mail list logo