CFG_BUILD_DIR, CFG_LLVM_SRC_DIR and CFG_SRC_DIR all have trailing
slashes, by definition, so this is correct.
(This is purely cosmetic; the doubled slash is ignored by all the tools we're using.)
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes#552
Earlier versions of pandoc don't have the `default.html5` template file. When `make docs` is run, the build process fails with this message.
pandoc: doc/rust.html
pandoc: /usr/share/pandoc-1.8.2.1/templates/default.html5: openFile: does not exist (No such file or directory)
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: write EPIPE
at errnoException (net.js:670:11)
at Object.afterWrite [as oncomplete] (net.js:503:19)
make: *** [doc/rust.html] Error 1
Previously we were actually overwriting `CFG_{HOST,TARGET,BUILD}` with `CFG_{HOST,TARGET,BUILD}_TRIPLE(S)` since configure tested for the legacy one by checking if it was empty which would never be the case. That meant it wouldn't split up multiple triples and just treat it as one long triple.
This pull also fixes the rules that were changed when librustuv was added to use the right CFG_ vars and removes the legacy flags.
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>
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.
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.
Since moving to a downloadable snapshot for stage0, it's been
possible to complete the build without compiling code written
in ocaml. However, the configure script still required it to
be present.
This commit changes detection failure to a non-fatal condition,
allowing the build to complete on systems without an ocaml
compiler.
An info message is also made conditional.
