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>
In order to mitigate typo of target-triples, error notification of unsupported target triples which defined in mk/platform.mk added.
minor fix for arm-linux-androideabi added.
- thanks to work in libuv's upstream, we can call libuv's Makefile directly
with parameters, instead of descending in gyp-uv madness and generating
our own.
Ubuntu's clang packages have additional information appended to the end of
the version.
- Building Rust v0.5 with clang v3.0-6ubuntu3 fails.
- Building Rust v0.5 and incoming with clang v3.1-5ppa (backported from Debian)
works.
Closes#4441.
This addresses issue #2720. According to LLVM's documentation, it requires a
version of Python between 2.4 and 2.7. Without the proper version, LLVM fails
to build with cryptic errors. Prior to this commit, the configure script
checked for the `python` command in the environment, but didn't actually check
the version, which can cause problems e.g. on Linux distros where the default
is Python 3. Now the configure script always prefers to select a more specific
version of Python when available, in the order `python2.7` > `python2.6` >
`python2` > `python`, and will always check to ensure that the interpreter's
version is in the correct range.
rather than the snapshots.
make sure to get all of the files.
update to add nmatsakis' requested feature of pointing to a
different rustc install root.
usage: --enable-local-rust to enable
--local-rust-root="/path/to/rustc/" to change the path, which defaults to
"/usr/local/"
Tested on OS X and Linux, likely broken on windows.
When CFG_ENABLE_DEBUG is defined it will call rustc with -g --cfg=debug
and cc with -DRUST_DEBUG. Otherwise it calls rustc with --cfg=ndebug and cc
with -DRUST_NDEBUG.
I plan to use this for a few things in the runtime.