Commit Graph

334 Commits

Author SHA1 Message Date
Gioele Barabucci ddeb3db872 Use system rustc if configured with --enable-local-rust
This commit makes the configuration system autodetect a rustc that
is already installed and use that instead of downloading a snapshot.
2014-08-07 15:55:10 +02:00
Michael Neumann 2e2f53fad2 Port Rust to DragonFlyBSD
Not included are two required patches:

* LLVM: segmented stack support for DragonFly [1]

* jemalloc: simple configure patches

[1]: http://reviews.llvm.org/D4705
2014-07-29 16:44:39 +02:00
Brian Anderson 04914fddfb configure: Add --enable-dist-host-only flag
This preserves the current behavior of `make dist` where we only
distribute bins for the host architecture. The bots need this.
2014-07-23 12:04:27 -07:00
Corey Richardson cbd6799110 lexer tests: makefile/configure 2014-07-21 18:37:17 -07:00
bors 206dd91742 auto merge of #14832 : alexcrichton/rust/no-rpath, r=brson
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.

This involved a few changes to the local build system:

* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
  in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
  component of LD_LIBRARY_PATH in more situations.

The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.

Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.

This change brings linux/mac installations in line with windows installations
where rpath is not possible.

Closes #11747
[breaking-change]
2014-07-08 22:51:39 +00:00
Steve Klabnik 3ed78f5b6b Add the Guide, add warning to tutorial.
In line with what @brson, @cmr, @nikomatsakis and I discussed this morning, my
redux of the tutorial will be implemented as the Guide. This way, I can work in
small iterations, rather than dropping a huge PR, which is hard to review.  In
addition, the community can observe my work as I'm doing it.

This adds a note in line with [this comment][reddit] that clarifies the state
of the tutorial, and the community's involvement with it.

[reddit]: http://www.reddit.com/r/rust/comments/28bew8/rusts_documentation_is_about_to_drastically/ci9c98k
2014-06-24 17:22:50 -07:00
Steve Klabnik e16a87513a Remove the cheat sheet.
Rust by Example is far better.

Fixes #14380.
2014-06-24 17:22:39 -07:00
Alex Crichton a0546ded10 rustc: Disable rpath settings by default
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.

This involved a few changes to the local build system:

* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
  in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
  component of LD_LIBRARY_PATH in more situations.

The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.

Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.

This change brings linux/mac installations in line with windows installations
where rpath is not possible.

Closes #11747
[breaking-change]
2014-06-16 21:55:38 -07:00
Alex Crichton 4cd932f94e alloc: Allow disabling jemalloc 2014-06-16 18:15:48 -07:00
Daniel Micay d884cc83b0 remove unnecessary PaX detection
Rust no longer has support for JIT compilation, so it doesn't currently
require a PaX MPROTECT exception. The extended attributes are preferred
over modifying the binaries so it's not actually going to work on most
systems like this anyway.

If JIT compilation ends up being supported again, it should handle this
by *always* applying the exception via an extended attribute without
performing auto-detection of PaX on the host. The `paxctl` tool is only
necessary with the older method involving modifying the ELF binary.
2014-06-13 13:53:35 -07:00
Alex Crichton 49fe690477 configure: Don't sync unused submodules
If the compiler is built with --{llvm,jemalloc,libuv}-root, then the configure
script can skip updating these submodules.

Closes #14822
2014-06-13 13:53:34 -07:00
Alex Crichton fa7b7bcdcb mk: Allow using a locally compiled libuv.a
Closes #5563
2014-06-12 00:29:58 -07:00
Alex Crichton 145e415fab mk: Allow usage of a local jemalloc install
This adds a new configure option, --jemalloc-root, which will specify a location
at which libjemalloc_pic.a must live. This library is then used for the build
triple as the jemalloc library to link.
2014-06-12 00:28:01 -07:00
Sylvestre Ledru fec04d387b Remove a warning (./configure: 1140: [: unexpected operator) when built with --disable-manage-submodules 2014-06-05 15:18:11 +02:00
Luqman Aden 3b56724c21 Don't enable libcpp for llvm by default. 2014-05-28 19:54:58 -07:00
bors 98c2b4b4ac auto merge of #13738 : buttslol/rust/armv7-support, r=alexcrichton
This was required to get ./configure to work on my armv7 test machine.

I haven't found anything sane to feature gate `hf` on that's pokable from the context of the configure script.

It also seems that gcc doesn't work on armv7 by default (rust wants to pass it `-m32` which isn't supported), would it be preferential to make the default `--enable-clang` on arm, or remove the `-m32` flag on that platform?
2014-05-28 11:06:42 -07:00
Richo Healey b4e69d4529 configure: setup triples on hf arm platforms 2014-05-27 23:42:35 -07:00
Richo Healey 8e3d2c39a8 configure: Only use -m32 on x86-* 32 bit systems 2014-05-27 23:37:46 -07:00
Richo Healey 2a63e44f12 configure: Move clang's libcpp out into flag 2014-05-27 23:36:36 -07:00
OGINO Masanori f36204c7e8 Use clang++ for CXX when --enable-clang.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
2014-05-27 18:48:32 +09:00
Felix S. Klock II ae67b74ec8 Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc.
I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.

The overall intention is to capture the following precedences for
guessing the C compiler:

 1. Value of `CC` at make invocation time.
 2. Value of `CC` at configure invocation time.
 3. Compiler inferred at configure invocation time (`gcc` or `clang`).

The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).

Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.

Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS`
values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings.
(This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various
parts of the mk files.)

Fix #13805.

----

Note that if you try to set the compiler to clang via the `CC` and
`CXX` environment variables, you will probably need to also set
`CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured
properly.

----

Introduce CFG_USING_CLANG, which is distinguished from
CFG_ENABLE_CLANG because the former represents "we think we're using
clang, choose appropriate warning-control options" while the latter
represents "we asked configure (or the host required) that we attempt
to use clang, so check that we have an appropriate version of clang."

The main reason I added this is that I wanted to allow the user to
choose clang via setting the `CC` environment variable, but I did not
want that method of selection to get confused with the user passing
the `--enable-clang` option.

----

A digression: The `configure` script does not infer the compiler
setting if `CC` is set; but if `--enable-clang` was passed, then it
*does* still attempt to validate that the clang version is compatible.

Supporting this required revising `CLANG_VERSION` check to be robust
in face of user-provided `CC` value.

In particular, on Travis, the `CC` is set to `gcc` and so the natural
thing to do is to attempt to use `gcc` as the compiler, but Travis is
also passing `--enable-clang` to configure.  So, what is the right
answer in the face of these contradictory requests?

One approach would be to have `--enable-clang` supersede the setting
for `CC` (and instead just call whatever we inferred for `CFG_CLANG`).
That sounds maximally inflexible to me (pnkfelix): a developer
requesting a `CC` value probably wants it respected, and should be
able to set it to something else; it is harder for that developer to
hack our configure script to change its inferred path to clang.

A second approach would be to blindly use the `CC` value but keep
going through the clang version check when `--enable-clang` is turned
on.  But on Travis (a Linux host), the `gcc` invocation won't print a
clang version, so we would not get past the CLANG_VERSION check in
that context.

A third approach would be to never run the CLANG_VERSION check if `CC`
is explicitly set.  That is not a terrible idea; but if the user uses
`CC` to pass in a path to some other version of clang that they want
to test, probably should still send that through the `CLANG_VERSION`
check.

So in the end I (pnkfelix) took a fourth approach: do the
CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string
ending with `clang`.  This way setting `CC` to things like
`path/to/clang` or `ccache clang` will still go through the
CLANG_VERSION check, while setting `CC` to `gcc` or some unknown
compiler will skip the CLANG_VERSION check (regardless of whether the
user passed --enable-clang to `configure`).

----

Drive-by fixes:

* The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in
  its invocation, but that does not play nicely with someone who sets
  `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret
  that whole string as a command.

  (On the other hand, a path with spaces might need the quoted
  invocation.  Not sure which one of these corner use-cases is more
  important to support.)

* Fix chk_cc error message to point user at `gcc` not `cc`.
2014-05-20 21:37:08 +02:00
Daniel Micay 1b1ca6d546 add back jemalloc to the tree
This adds a `std::rt::heap` module with a nice allocator API. It's a
step towards fixing #13094 and is a starting point for working on a
generic allocator trait.

The revision used for the jemalloc submodule is the stable 3.6.0 release.

Closes #11807
2014-05-10 19:58:17 -04:00
Michael Woerister 55a8bd56e5 debuginfo: Split debuginfo autotests into debuginfo-gdb and debuginfo-lldb 2014-05-07 19:58:07 +02:00
Alex Crichton 7b2a89fa75 test: Add a compile-fail-fulldeps test suite
Compile-fail tests for syntax extensions belong in this suite which has correct
dependencies on all artifacts rather than just the target artifacts.

Closes #13818
2014-04-28 17:31:43 -07:00
Alex Crichton acdee8b904 llvm: Add an option to statically link libstdc++
The goal of the snapshot bots is to produce binaries which can run in as many
locations as possible. Currently we build on Centos 6 for this reason, but with
LLVM's update to C++11, this reduces the number of platforms that we could
possibly run on.

This adds a --enable-llvm-static-stdcpp option to the ./configure script for
Rust which will enable building a librustc with a static dependence on
libstdc++. This normally isn't necessary, but this option can be used on the
snapshot builders in order to continue to make binaries which should be able to
run in as many locations as possible.
2014-04-17 11:39:51 -07:00
Alex Crichton 682c401045 configure: Enable clang for older OSX gcc versions
OSX often has a more recent version of clang than it does for GCC. When an older
version of gcc is detected on OSX, the --enable-clang flag is implicitly
enabled.
2014-04-17 11:11:39 -07:00
Alex Crichton 32a81d1e16 configure: Enable libc++ with LLVM with clang
When clang is enabled, also pass through --enable-libcpp to LLVM's configure
command line to help it pick up the most recent c++ runtime library. This also
changes the mklldeps.py script to pick up on whether LLVM was linked against
stdc++ or c++ based on the --cxxflags that llvm-config prints.

In an ongoing attempt to update LLVM, the bots need to update their C compilers
to something that supports c++11 (LLVM recently switched). The OSX bots are
running Lion (10.7), which only supports up to gcc 4.2 and clang 3.2. Apparently
the libstdc++ is too old (even on the most updated command line tools) for LLVM,
but using libc++ instead appears to work just fine.
2014-04-17 11:11:39 -07:00
Alex Crichton 30ff17f809 Upgrade LLVM
This comes with a number of fixes to be compatible with upstream LLVM:

* Previously all monomorphizations of "mem::size_of()" would receive the same
  symbol. In the past LLVM would silently rename duplicated symbols, but it
  appears to now be dropping the duplicate symbols and functions now. The symbol
  names of monomorphized functions are now no longer solely based on the type of
  the function, but rather the type and the unique hash for the
  monomorphization.

* Split stacks are no longer a global feature controlled by a flag in LLVM.
  Instead, they are opt-in on a per-function basis through a function attribute.
  The rust #[no_split_stack] attribute will disable this, otherwise all
  functions have #[split_stack] attached to them.

* The compare and swap instruction now takes two atomic orderings, one for the
  successful case and one for the failure case. LLVM internally has an
  implementation of calculating the appropriate failure ordering given a
  particular success ordering (previously only a success ordering was
  specified), and I copied that into the intrinsic translation so the failure
  ordering isn't supplied on a source level for now.

* Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions,
  etc.
2014-04-17 11:11:39 -07:00
Alex Crichton 9f990f74b3 configure: Accept LLVM 3.4.X during configuration
The previous regex was a bit to strict, rejecting versions such as 3.4.1 which
is apparently the version which travis is currently installing, causing all
travis builds to fail.
2014-03-30 13:54:57 -07:00
klutzy d9d197d9fc configure: Add MINGW64 OS type
MSYS2 supports `MINGW64` system for 64-bit environment. It sets
`MSYSTEM=MINGW64` environment variable, which changes output of
`uname -s` thus affects `configure` behavior.

This patch adds `MINGW64*` support for `configure`.
2014-03-30 04:34:40 +09:00
bors 363198bca0 auto merge of #13193 : pongad/rust/fixconfig, r=thestinger
Fixes #13147

Not a shell pro myself, though after running the new config, make and make check still work ok.
2014-03-29 04:51:38 -07:00
Michael Darakananda 092eefcfb2 configure uses `command -v` instead of `which` #13147 2014-03-29 00:16:58 -04:00
Brian Anderson 01d823b4de install: Verify that installed compiler runs
Another sanity check. Can be disabled in `install.sh` via `--disable-verify`
and `configure` with `--disable-verify-install`.
2014-03-28 15:50:32 -07:00
Brian Anderson 00f7776daa mk: Make nightlyism a configure option 2014-03-25 21:35:10 -07:00
Brian Anderson 6f9b30c6c1 configure: Make rustlibdir non-configurable
Trying to reduce the complexity of installation
2014-03-25 21:35:10 -07:00
bors 74bfa7108a auto merge of #12783 : adrientetar/rust/more-docs, r=alexcrichton
- remove `node.js` dep., it has no effect as of #12747 (1)
- switch between LaTeX compilers, some cleanups
- CSS: fixup the print stylesheet, refactor highlighting code (2)

(1): `prep.js` outputs its own HTML directives, which `pandoc` cannot recognize when converting the document into LaTeX (this is why the PDF docs have never been highlighted as of now).

Note that if we were to add the `.rust` class to snippets, we could probably use pandoc's native highlighting capatibilities i.e. Kate ([here is](http://adrientetar.github.io/rust-tuts/tutorial/tutorial.pdf) an example of that).

(2): the only real highlighting change is for lifetimes which are now brown instead of red, the rest is just refactor of twos shades of red that look the same.
Also I made numbers highlighting for src in rustdoc a tint more clear so that it is less bothering.

@alexcrichton, @huonw

Closes #9873. Closes #12788.
2014-03-11 12:36:58 -07:00
Brian Anderson 16ec0ab542 configure: Create the dist directory 2014-03-09 14:17:26 -07:00
Brian Anderson 99746d43c1 Bugfixes and cleanup to configure script 2014-03-09 14:17:26 -07:00
Adrien Tétar 9eadcacdd7 doc: have a real switch b/w LaTeX compilers 2014-03-09 18:44:59 +01:00
Adrien Tétar 862acedf51 doc: remove node.js dependency
`prep.js` outputs its own HTML directives, which `pandoc` cannot
recognize when converting the document into LaTeX (this is why the
PDF docs have never been highlighted as of now).

Note that if we were to add the `.rust` class to snippets, we could
probably use pandoc's native highlighting capatibilities i.e. Kate.
2014-03-09 13:45:36 +01:00
Gary M. Josack 7e85431775 Remove references to guide-conditions
std::condition was removed in 454882dcb7
but there are still links to the guide. Removing them.
2014-02-25 01:01:55 -08:00
Alex Crichton ea72398adf configure: Accept LLVM 3.5 for building rust
This is the current head of LLVM, and we can indeed build with 3.5
2014-02-20 18:07:08 -08:00
Brian Anderson 8d4b675ced mk: Address review feedback 2014-02-14 19:17:50 -08:00
Brian Anderson 334af011f0 mk: Improve build system help commands 2014-02-14 17:45:54 -08:00
Brian Anderson 94d2c8a21f mk: Remove the concept of 'snapshot transitions'
This way of doing snapshots hasn't been used since 2011.
2014-02-14 17:45:53 -08:00
Alex Crichton 8cd935f52a Upgrade LLVM
This upgrade brings commit by @eddyb to help optimizations of virtual calls in
a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a
commit by @c-a to *greatly* improve the runtime of the optimization passes
(https://github.com/rust-lang/llvm/pull/3).

Nice work to these guys!
2014-01-29 23:43:39 -08:00
Alex Crichton e715cdba31 Allow opting-out of rpath usage
By default, the compiler and libraries are all still built with rpaths, but this
can be opted out of with --disable-rpath to ./configure or --no-rpath to rustc.

cc #5219
2014-01-24 09:24:45 -08:00
Alex Crichton 7a37294acc Add a configure to disable libstd version injection
We'll use this when building snapshots so we can upgrade freely, but all
compilers will inject a version by default.
2014-01-15 08:22:16 -08:00
bors dd8b011319 auto merge of #11521 : dguenther/rust/hide_libdir_relative, r=alexcrichton
Renamed `LIBDIR_RELATIVE` to `CFG_LIBDIR_RELATIVE`. It's not a configurable variable, but it looks out of place without the `CFG_` prefix.

Fixes #11420
2014-01-14 15:11:30 -08:00
Derek Guenther a599d897fc Renamed LIBDIR_RELATIVE to CFG_LIBDIR_RELATIVE 2014-01-14 15:52:57 -06:00