As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
Closes#9925
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
Builds are considerably faster without assertions, so when working on
e.g. libstd, which doesn't directly interact with LLVM, one might want
to disable them.
Closes#3816.
Without --quiet, git shows its own progress report of download. It's not really a progress bar, but it's a percentage and files incoming. This will help initial downloads of LLVM to not cause people to wonder why their configure script is hanging for hours.
r? @graydon
When no arguments are given, echo prints a blank line. These two are
equivalent:
$ echo ""
$ echo
Replace the former by the latter.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Fix#6805: add --enable-ccache configure option to prefix compiler invocations with `ccache` to attempt to reuse common results, e.g. for LLVM (re)builds.
The information at developer [Note-ccache](../../wiki/Note-ccache) and at [ccache and clang concerns](http://petereisentraut.blogspot.fr/2011/09/ccache-and-clang-part-2.html) were what drove my introduction of the `-Qunused-arguments` and `CCACHE_CPP2` options. (Though I did confirm first-hand that at least the first really is necessary.)
Yes, one certainly can re-route how `gcc` and `clang` are resolved in one's PATH and use that as a way to invoke `ccache`. But I personally do not want to introduce that change to my own PATH, and this seems like a small enough change that it does not hurt to add it, at least for now. (I don't know what form it would take when we move over to `rustpkg`.)
Apple Clang uses different version numbering than "regular" clang, but
it also provides the "regular" version it's based on. Update the sed
pattern to pull out this "regular" version number instead of the Apple
version number.
This lets us use #ifdefs to determine which stage of the build we happen
to be in, which is useful in the event we need to make changes to rustrt
that are incompatible with the code generated by stage0.
This should help pave the way to completing #6575, which will likely
require changes to type signatures for spawn_fn & glue_fn in rustrt.
* They didn't work before, because the location of the tests caused the
'sysroot' option to crate lookup to be wrong for finding the correct stage's
core/std libraries. This moves the compiled tests from the $host/test
directory into a $host/$stage/test directory. This means that the sysroot will
be correct and the core/std libraries can actually be found
* The LLVM bindings apparently aren't threadsafe, so we can't run multiple tests
in parallel.
Removing it from the tree is an ordeal and there is no official way
to disable clang via LLVM's Makefiles so this edits the Makefile
in llvm/tools after running configure.
Previously the build system only checked for llvm-3.1 - 2.8.
Now also 3.2 and 3.2svn is accepted.
Signed-off-by: Fabian Deutsch <fabian.deutsch@gmx.de>
Previously the build system only checked for llvm-3.1 - 2.8.
Now also 3.2 and 3.2svn is accepted.
Signed-off-by: Fabian Deutsch <fabian.deutsch@gmx.de>
