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.
Linux perf tool version 3.2 introduced a new option "--log-fd" defaults
to 0, which leads to error "Failed opening logfd: Illegal argument" when
executing perf tests.
Set logfd to stderr to let perf test work.
Issue #1538
Naturaldocs isn't really that great but it seems easier to get
something working than with doxygen, for which we would need to
convert rust code to something C++ish. We probably want to just
write a rustdoc utility at some point.
On my machine I have two LLVM builds, one of regular HEAD and one
for Rust in ~/rust-llvm - by default CFG_LLVM_CONFIG is set to
/usr/local/bin/llvm-config which is wrong, because the probe for it
initially happens earlier in configure and succeeds (so putvar is called.)
This causes it to be emitted twice into the Makefile but the second
instance wins.
This splits mk/stageN.mk into host.mk and target.mk and makes
the build rules somewhat simpler - there's no more building from stageN
into stageN+1; instead we always build from stageN(host) to
stageN(target) then promote from stageN(target) to stageN+1(host).
Add a big honkin explaination right at the top of Makefile.in
This patch changes libuv's gyp build system to
make it's own makefiles. To generate them for rust,
run these commands. They requires python 2.x to
work:
$ mkdir -p src/rt/libuv/build
$ svn co http://gyp.googlecode.com/svn src/rt/libuv/build/gyp
$ ./etc/src/gyp_uv
Add a new src/test/pretty directory to hold just source files for testing the
pretty-printer.
Add a new pp-exact directive. When this directive is followed by a file name
it specifies a file containing the output that the pretty-printer should
generate. When pp-exact is not followed by a filename it says that the file
should pretty-print as written.
This replaces the make-based test runner with a set of Rust-based test
runners. I believe that all existing functionality has been
preserved. The primary objective is to dogfood the Rust test
framework.
A few main things happen here:
1) The run-pass/lib-* tests are all moved into src/test/stdtest. This
is a standalone test crate intended for all standard library tests. It
compiles to build/test/stdtest.stageN.
2) rustc now compiles into yet another build artifact, this one a test
runner that runs any tests contained directly in the rustc crate. This
allows much more fine-grained unit testing of the compiler. It
compiles to build/test/rustctest.stageN.
3) There is a new custom test runner crate at src/test/compiletest
that reproduces all the functionality for running the compile-fail,
run-fail, run-pass and bench tests while integrating with Rust's test
framework. It compiles to build/test/compiletest.stageN.
4) The build rules have been completely changed to use the new test
runners, while also being less redundant, following the example of the
recent stageN.mk rewrite.
It adds two new features to the cfail/rfail/rpass/bench tests:
1) Tests can specify multiple 'error-pattern' directives which must be
satisfied in order.
2) Tests can specify a 'compile-flags' directive which will make the
test runner provide additional command line arguments to rustc.
There are some downsides, the primary being that Rust has to be
functioning pretty well just to run _any_ tests, which I imagine will
be the source of some frustration when the entire test suite
breaks. Will also cause some headaches during porting.
Not having individual make rules, each rpass, etc test no longer
remembers between runs whether it completed successfully. As a result,
it's not possible to incrementally fix multiple tests by just running
'make check', fixing a test, and repeating without re-running all the
tests contained in the test runner. Instead you can filter just the
tests you want to run by using the TESTNAME environment variable.
This also dispenses with the ability to run stage0 tests, but they
tended to be broken more often than not anyway.
This will link to std and compile with the --test flag. Eventually the
run-pass/lib* tests will move here.
We could also put the std tests directly into the library and compile both a
library version and a test version, but I think this way will make for faster
builds.
Issue #428
On some platform (OS X), llvm needs macros like
__STDC_LIMIT_MACROS defined in order to work, which is
normally defined in llvm-config. This patch modifies
the config to use CFG_LLVM_ROOT's llvm-config if it
exists, which fixes the compile failures.
