Commit Graph

654 Commits

Author SHA1 Message Date
bors
d89a10b0a6 Auto merge of #28340 - brson:configure, r=alexcrichton
Redirect stdout on the python bogosity detector. This is printing
pwd to the terminal currently.

Reformat the bogus python/cmake messages so they format correctly.
echo does not always escape newlines (it doesn't here), and multiline
strings don't whitespace munch.

r? @alexcrichton
2015-09-12 02:57:01 +00:00
Brian Anderson
2662a72537 configure cleanup on windows
Redirect stdout on the python bogosity detector. This is printing
pwd to the terminal currently.

Reformat the bogus python/cmake messages so they format correctly.
echo does not always escape newlines (it doesn't here), and multiline
strings don't whitespace munch.
2015-09-11 14:33:29 -07:00
bors
5c56887903 Auto merge of #28331 - semarie:openbsd-configure-egcc, r=alexcrichton
under OpenBSD, it could be have present multiples versions of gcc compiler:
  - gcc-4.2 (with patchs) : c/c++ compiler present in `/usr/bin`. It is unusable to build recent LLVM (so rustc too).
  - gcc/g++ -4.9 : c/c++ compiler, installed as third-party with "ports" mechanism. The compiler is installed in `/usr/local` as `egcc` (and `eg++`).

this PR adds probing for `egcc` for `CFG_GCC`, if the first probed `gcc` is too old. It will set `CC` and `CXX` too, in order to pass the variables to LLVM configure if builded.

please note this PR is a first step in order to build rustc under OpenBSD with unpatched tree.

r? @alexcrichton

cc @brson @dhuseby
2015-09-10 23:33:31 +00:00
Sébastien Marie
9ac36f4665 disable jemalloc on OpenBSD
depending of the compiler used, jemalloc configure don't detect
correctly some parameters.
2015-09-10 18:52:19 +02:00
Sébastien Marie
90043cbbf0 openbsd: probe CFG_GCC egcc
if default CFG_GCC is too old, probe also egcc (which is gcc from
ports).

set CC/CXX too, in order to pass them to LLVM
2015-09-10 11:59:01 +02:00
Dong Zhou
0ad631cf7c Fix clang too 2015-09-09 11:45:59 -04:00
Dong Zhou
d77a249917 Fix configure for LLVM 3.8 2015-09-09 11:32:05 -04:00
Diggory Blake
f86c853fee Fix escaping in msvc builds 2015-09-04 10:03:56 +01:00
Tim JIANG
a1b2deb33b New cross target: i686-linux-android
- All the libstd tests are now passing in the optimized build against
  a Zenfone2 and the x86 Android simulator.
2015-08-23 15:38:11 +08:00
Marc-Antoine Perennou
c977596992 rustc_back: add configure options for default linker and ar
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2015-08-19 18:06:34 +02:00
Sylvestre Ledru
5bcbc5c735 Bug #27621 - Make sure that LLVM FileCheck is available on the system 2015-08-10 09:53:00 +02:00
Dave Huseby
40eb53c409 recent changes to search for gcc/clang on freebsd and this fixes #14381 2015-07-28 21:23:19 -07:00
bors
aa6efd959e Auto merge of #27173 - mark-buer:split-android-ndks, r=alexcrichton
Allows a multi-Android-target Rust compiler to be built.
Without these (or similar) changes, only a single-Android-target Rust compiler is possible.
Please see https://internals.rust-lang.org/t/dual-target-android-rust-compiler/2382/3 for additional context.
2015-07-28 17:58:18 +00:00
Mark Buer
33a7e67904 Splits Android NDK path configuration. 2015-07-28 19:21:04 +12:00
bors
8b835572b9 Auto merge of #27250 - alexcrichton:ucrt, r=brson
Visual Studio 2015, recently released, includes the Universal CRT, a different
flavor than was provided before. The binaries and header files for this library
are included in new locations not previously known about by gcc-rs, and this
commit adds support for the necessary probing to find these.

Unfortunately there are no prior examples of this probing to be found in
frameworks like CMake or clang, so this is done is a bit of a sketchy method
today. It assumes that the installation is in a relatively standard format and
then blindly looks for the location of the UCRT. I'd love to switch this over to
using registry keys for probing, but I was currently unable to find such keys.

This should enable the compiler to work outside VS 2015 dev tools prompts.
2015-07-27 23:38:04 +00:00
Steven Stewart-Gallus
f3bfbda665 Standardize on non-zero checks for configure 2015-07-26 14:18:30 -07:00
Alex Crichton
95ec4be02b configure: Add support for VS 2015
Adds support to the configure script for detecting Visual Studio 2015 being
installed and builds LLVM/uses cl with that compiler. The compiler will
automatically use this MSVC linker anyway because it's the highest version.
2015-07-23 19:38:00 -07:00
Felix S. Klock II
ac33f1572b fix configure: allow both --enable-debug and --disable-debuginfo
in one invocation.
2015-07-20 10:07:53 +02:00
Manish Goregaokar
2c49927ae4 Rollup merge of #27028 - Gankro:travis, r=alexcrichton
This has travis build LLVM and rustc up to stage1, but not run any tests. It seems wasteful to have the ultimate might of travis running on every PR just to check for whitespace errors. This is a pure subset of the bootstrap, so it shouldn't ever spuriously break.

`make tidy` still runs first, so we still get \"fast errors\" on bad style. However once make tidy passes, the build will simply keep running to try to make rustc. `tidy` takes ~3 mins to complete, so if your build runs longer you can be confident we've gone on to build LLVM/rustc. In principle this is configured to use ccache (it shows up in the build logs as uploaded/downloaded), but I found no actual performance changes in using it.

Maybe someone at @travis-ci knows what's up with that.

For reference, here is a successful build with ccache enabled: https://travis-ci.org/Gankro/rust/builds/70821237

and one without: https://travis-ci.org/Gankro/rust/builds/70812814

Builds seem to take about 41mins regardless.

r? @alexcrichton
2015-07-16 10:49:23 +05:30
Alexis Beingessner
e8a03285b7 Ratchet up travis to build stage1 and our own LLVM.
Tidy is still run first for failing fast on the easy stuff.

To accomplish this we have travis actually persist ccache across builds. This
has LLVM built within 6 minutes, and all of stage1 built within 18.
Caching should work on fresh PRs (cache acquired from the master branch).
Because all we persist is ccache, there is minimal danger of persisting corrupt
build state.

I had to mangle `configure` a bit to make --enable-ccache work when custom
compilers are provide via CC and CXX.
2015-07-15 10:48:50 -07:00
Ryan Pendleton
7131e6f378 verify Apple LLVM versions independently, since the "based on LLVM" version is no longer reported 2015-07-13 00:33:36 -06:00
Alex Newman
0b7c4f57f6 Add netbsd amd64 support 2015-07-01 19:09:14 -07:00
Alex Crichton
ae36d4f72a mk: Add support for i686-pc-windows-msvc
This commit modifies the configure script and our makefiles to support building
32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can
produce a 32-bit or 64-bit binary. The configure script was updated to export
more variables at configure time, and the makefiles were rejiggered to
selectively reexport the relevant environment variables for the applicable
targets they're going to run for.
2015-06-27 13:02:18 -07:00
Dave Huseby
44d487d37c stupid missing dollar sign 2015-06-24 12:48:08 -07:00
Dave Huseby
97fb1c241c adding fallback to clang if gcc not available 2015-06-24 12:39:58 -07:00
Dave Huseby
4de71c7ef6 allowing fallback to clang on freebsd when needed 2015-06-24 12:39:58 -07:00
Sébastien Marie
e0283ab9c4 support llvm version 3.7 in configure
LLVM version 3.7 should be supported as external version (when using
--llvm-root configure option), as the current embedded LLVM version is
3.7.0svn.
2015-06-24 08:36:42 +02:00
OGINO Masanori
59399088ca Put CFG_BUILD triples into CFG_HOST triples.
I've configured with the parameters suggested by @brson in #18670 and
confirmed that it works on Gentoo Linux amd64.

Fixes #18670.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
2015-06-22 12:53:34 +09:00
Ulrik Sverdrup
70269cd8ef mk: Build crates with relative paths to rustc
The path we pass to rustc will be visible in panic messages and
backtraces: they will be user visible!

Avoid junk in these paths by passing relative paths to rustc.

For most advanced users, `libcore` or `libstd` in the path will be
a clue to the location -- inside our code, not theirs.

Store both the relative path to the source as well as the absolute.
Use the relative path where it matters, compiling the main crates,
instead of changing all of the build process to cope with relative
paths.

Example output after this patch:

```
$ ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
$ RUST_BACKTRACE=1 ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
stack backtrace:
   1:     0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des
                        at ../src/libstd/sys/unix/backtrace.rs:158
   2:     0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw
                        at ../src/libstd/panicking.rs:58
   3:     0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw
                        at ../src/libstd/rt/unwind/mod.rs:273
   4:     0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw
                        at ../src/libstd/rt/unwind/mod.rs:212
   5:     0x7ff59c1eced7 - rust_begin_unwind
   6:     0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B
                        at ../src/libcore/panicking.rs:64
   7:     0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B
                        at ../src/libcore/panicking.rs:45
   8:     0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829
   9:     0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa
  10:     0x7ff59c1f1c18 - rust_try_inner
  11:     0x7ff59c1f1c05 - rust_try
  12:     0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw
                        at ../src/libstd/rt/unwind/mod.rs:147
                        at ../src/libstd/rt/unwind/mod.rs:130
                        at ../src/libstd/rt/mod.rs:128
  13:     0x7ff59c1e628e - main
  14:     0x7ff59b3f6b44 - __libc_start_main
  15:     0x7ff59c1e6078 - <unknown>
  16:                0x0 - <unknown>
```
2015-06-13 01:41:52 +02:00
Alex Crichton
3d74fbd496 configure: Fix LLVM output dir on MSVC
If LLVM assertions are enabled for MSVC, it looks like the output directory is
still just `Release` (or assertions are just always ignored on MSVC).
2015-06-03 22:08:47 -07:00
bors
5b56d73dc0 Auto merge of #25984 - Manishearth:rollup, r=Manishearth
- Successful merges: #25939, #25963, #25970, #25971, #25974
- Failed merges:
2015-06-03 09:44:26 +00:00
Manish Goregaokar
27dd5e9ce9 Rollup merge of #25971 - richo:configurable-python, r=alexcrichton
r? @alexcrichton
2015-06-03 14:46:41 +05:30
Manish Goregaokar
3fd41d61ab Rollup merge of #25939 - wca:fix-freebsd-configure, r=alexcrichton
Bug fixes for configure on FreeBSD:
- Don't ban using gcc; newer versions can be installed and other checks should enforce its suitability.
- Don't force Rust to link itself with /usr/local/lib{,gcc4[46]}, which causes builds to fail if Rust is already installed.  I've not been able to find an use case where this is actually necessary.
2015-06-03 14:46:40 +05:30
bors
a5979be9fe Auto merge of #25938 - wca:fix-clang-check-compatibility, r=alexcrichton
Not all /bin/sh have [[ available, so for compatibility using case..esac
for pattern matching is better.
2015-06-03 06:07:44 +00:00
Richo Healey
de4a1dca2b configure: Allow specifying your python with --python 2015-06-02 15:16:30 -07:00
bors
a49ae5bd43 Auto merge of #25858 - alexcrichton:disable-os-tls, r=brson
This commit adds a ./configure option called `--disable-elf-tls` which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.

Closes #25342
2015-06-01 19:51:57 +00:00
Andrew Foote
d4389c52ab remove duplicate "don't" 2015-05-30 18:13:51 -07:00
Alex Crichton
1b5f9cb1f1 std: Add an option to disable ELF based TLS
This commit adds a ./configure option called `--disable-elf-tls` which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.
2015-05-28 10:14:42 -07:00
Kubilay Kocak
d323c14f63 Remove redundant compiler check. Allow CC override
Currently, there are two conditional blocks that exist to check for "clang or gcc"

On line 866:

```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
    err "either clang or gcc is required"
fi
```
and on line 1019:

```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
    err "either clang or gcc is required"
fi
```

Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set. 

The expected behaviour is to honour user-flags, in this case CC.

Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
2015-05-26 18:23:33 +10:00
Will Andrews
bc85eb49f5 Use case..esac instead of [[.
Not all /bin/sh have [[ available, so for compatibility using case..esac
for pattern matching is better.
2015-05-23 14:11:50 -06:00
Will Andrews
31764a98ff Don't force FreeBSD to use clang.
Newer gcc can be installed, so it should be used if possible.  Checks
elsewhere in configure should enforce this.
2015-05-23 14:09:11 -06:00
Oliver Schneider
a650075f89 Rollup merge of #25722 - nickdesaulniers:configureClang37, r=brson
Was able to successfully configure.  Building and testing now.
2015-05-23 19:03:20 +02:00
Nick Desaulniers
64f8640164 allow clang 3.7 to be used when configuring Fixes #25720 2015-05-22 16:07:25 -07:00
Geoffrey Thomas
dfacdcf25d configure: Fix printing of commands from run
The `run` function passed its argument to `msg` via `"$@"`, but `msg`
only printed its first argument. I think the intention was for `msg` to
print all its arguments. (If not, `run` should only `msg "$1"`.)
2015-05-22 00:39:24 -04:00
Geoffrey Thomas
1e180b809f configure: Clarify error message about missing dependencies
Took me a moment to figure out that the appropriate response to
"need program file" was to install the program named "file", not
to think "If I didn't need the program file, why would I be
compiling things?".
2015-05-22 00:38:49 -04:00
Sébastien Marie
0cac79181b use posix command to extract first 8 chars
the "-c" option of head isn't a posix option, and it isn't supported
under openbsd.

prefer the use of cut -c 1-8 (which is posix) to extract the first 8
chars.
2015-05-20 13:54:14 +02:00
bors
43cf733bfa Auto merge of #25350 - alexcrichton:msvc, r=brson
Special thanks to @retep998 for the [excellent writeup](https://github.com/rust-lang/rfcs/issues/1061) of tasks to be done and @ricky26 for initially blazing the trail here!

# MSVC Support

This goal of this series of commits is to add MSVC support to the Rust compiler
and build system, allowing it more easily interoperate with Visual Studio
installations and native libraries compiled outside of MinGW.

The tl;dr; of this change is that there is a new target of the compiler,
`x86_64-pc-windows-msvc`, which will not interact with the MinGW toolchain at
all and will instead use `link.exe` to assemble output artifacts.

## Why try to use MSVC?

With today's Rust distribution, when you install a compiler on Windows you also
install `gcc.exe` and a number of supporting libraries by default (this can be
opted out of). This allows installations to remain independent of MinGW
installations, but it still generally requires native code to be linked with
MinGW instead of MSVC. Some more background can also be found in #1768 about the
incompatibilities between MinGW and MSVC.

Overall the current installation strategy is quite nice so long as you don't
interact with native code, but once you do the usage of a MinGW-based `gcc.exe`
starts to get quite painful.

Relying on a nonstandard Windows toolchain has also been a long-standing "code
smell" of Rust and has been slated for remedy for quite some time now. Using a
standard toolchain is a great motivational factor for improving the
interoperability of Rust code with the native system.

## What does it mean to use MSVC?

"Using MSVC" can be a bit of a nebulous concept, but this PR defines it as:

* The build system for Rust will build as much code as possible with the MSVC
  compiler, `cl.exe`.
* The build system will use native MSVC tools for managing archives.
* The compiler will link all output with `link.exe` instead of `gcc.exe`.

None of these are currently implemented today, but all are required for the
compiler to fluently interoperate with MSVC.

## How does this all work?

At the highest level, this PR adds a new target triple to the Rust compiler:

    x86_64-pc-windows-msvc

All logic for using MSVC or not is scoped within this triple and code can
conditionally build for MSVC or MinGW via:

    #[cfg(target_env = "msvc")]

It is expected that auto builders will be set up for MSVC-based compiles in
addition to the existing MinGW-based compiles, and we will likely soon start
shipping MSVC nightlies where `x86_64-pc-windows-msvc` is the host target triple
of the compiler.

# Summary of changes

Here I'll explain at a high level what many of the changes made were targeted
at, but many more details can be found in the commits themselves. Many thanks to
@retep998 for the excellent writeup in rust-lang/rfcs#1061 and @rick26 for a lot
of the initial proof-of-concept work!

## Build system changes

As is probably expected, a large chunk of this PR is changes to Rust's build
system to build with MSVC. At a high level **it is an explicit non goal** to
enable building outside of a MinGW shell, instead all Makefile infrastructure we
have today is retrofitted with support to use MSVC instead of the standard MSVC
toolchain. Some of the high-level changes are:

* The configure script now detects when MSVC is being targeted and adds a number
  of additional requirements about the build environment:
  * The `--msvc-root` option must be specified or `cl.exe` must be in PATH to
    discover where MSVC is installed. The compiler in use is also required to
    target x86_64.
  * Once the MSVC root is known, the INCLUDE/LIB environment variables are
    scraped so they can be reexported by the build system.
  * CMake is required to build LLVM with MSVC (and LLVM is also configured with
    CMake instead of the normal configure script).
  * jemalloc is currently unconditionally disabled for MSVC targets as jemalloc
    isn't a hard requirement and I don't know how to build it with MSVC.
* Invocations of a C and/or C++ compiler are now abstracted behind macros to
  appropriately call the underlying compiler with the correct format of
  arguments, for example there is now a macro for "assemble an archive from
  objects" instead of hard-coded invocations of `$(AR) crus liboutput.a ...`
* The output filenames for standard libraries such as morestack/compiler-rt are
  now "more correct" on windows as they are shipped as `foo.lib` instead of
  `libfoo.a`.
* Rust targets can now depend on native tools provided by LLVM, and as you'll
  see in the commits the entire MSVC target depends on `llvm-ar.exe`.
* Support for custom arbitrary makefile dependencies of Rust targets has been
  added. The MSVC target for `rustc_llvm` currently requires a custom `.DEF`
  file to be passed to the linker to get further linkages to complete.

## Compiler changes

The modifications made to the compiler have so far largely been minor tweaks
here and there, mostly just adding a layer of abstraction over whether MSVC or a
GNU-like linker is being used. At a high-level these changes are:

* The section name for metadata storage in dynamic libraries is called `.rustc`
  for MSVC-based platorms as section names cannot contain more than 8
  characters.
* The implementation of `rustc_back::Archive` was refactored, but the
  functionality has remained the same.
* Targets can now specify the default `ar` utility to use, and for MSVC this
  defaults to `llvm-ar.exe`
* The building of the linker command in `rustc_trans:🔙:link` has been
  abstracted behind a trait for the same code path to be used between GNU and
  MSVC linkers.

## Standard library changes

Only a few small changes were required to the stadnard library itself, and only
for minor differences between the C runtime of msvcrt.dll and MinGW's libc.a

* Some function names for floating point functions have leading underscores, and
  some are not present at all.
* Linkage to the `advapi32` library for crypto-related functions is now
  explicit.
* Some small bits of C code here and there were fixed for compatibility with
  MSVC's cl.exe compiler.

# Future Work

This commit is not yet a 100% complete port to using MSVC as there are still
some key components missing as well as some unimplemented optimizations. This PR
is already getting large enough that I wanted to draw the line here, but here's
a list of what is not implemented in this PR, on purpose:

## Unwinding

The revision of our LLVM submodule [does not seem to implement][llvm] does not
support lowering SEH exception handling on the Windows MSVC targets, so
unwinding support is not currently implemented for the standard library (it's
lowered to an abort).

[llvm]: https://github.com/rust-lang/llvm/blob/rust-llvm-2015-02-19/lib/CodeGen/Passes.cpp#L454-L461

It looks like, however, that upstream LLVM has quite a bit more support for SEH
unwinding and landing pads than the current revision we have, so adding support
will likely just involve updating LLVM and then adding some shims of our own
here and there.

## dllimport and dllexport

An interesting part of Windows which MSVC forces our hand on (and apparently
MinGW didn't) is the usage of `dllimport` and `dllexport` attributes in LLVM IR
as well as native dependencies (in C these correspond to
`__declspec(dllimport)`).

Whenever a dynamic library is built by MSVC it must have its public interface
specified by functions tagged with `dllexport` or otherwise they're not
available to be linked against. This poses a few problems for the compiler, some
of which are somewhat fundamental, but this commit alters the compiler to attach
the `dllexport` attribute to all LLVM functions that are reachable (e.g. they're
already tagged with external linkage). This is suboptimal for a few reasons:

* If an object file will never be included in a dynamic library, there's no need
  to attach the dllexport attribute. Most object files in Rust are not destined
  to become part of a dll as binaries are statically linked by default.
* If the compiler is emitting both an rlib and a dylib, the same source object
  file is currently used but with MSVC this may be less feasible. The compiler
  may be able to get around this, but it may involve some invasive changes to
  deal with this.

The flipside of this situation is that whenever you link to a dll and you import
a function from it, the import should be tagged with `dllimport`. At this time,
however, the compiler does not emit `dllimport` for any declarations other than
constants (where it is required), which is again suboptimal for even more
reasons!

* Calling a function imported from another dll without using `dllimport` causes
  the linker/compiler to have extra overhead (one `jmp` instruction on x86) when
  calling the function.
* The same object file may be used in different circumstances, so a function may
  be imported from a dll if the object is linked into a dll, but it may be
  just linked against if linked into an rlib.
* The compiler has no knowledge about whether native functions should be tagged
  dllimport or not.

For now the compiler takes the perf hit (I do not have any numbers to this
effect) by marking very little as `dllimport` and praying the linker will take
care of everything. Fixing this problem will likely require adding a few
attributes to Rust itself (feature gated at the start) and then strongly
recommending static linkage on Windows! This may also involve shipping a
statically linked compiler on Windows instead of a dynamically linked compiler,
but these sorts of changes are pretty invasive and aren't part of this PR.

## CI integration

Thankfully we don't need to set up a new snapshot bot for the changes made here as our snapshots are freestanding already, we should be able to use the same snapshot to bootstrap both MinGW and MSVC compilers (once a new snapshot is made from these changes).

I plan on setting up a new suite of auto bots which are testing MSVC configurations for now as well, for now they'll just be bootstrapping and not running tests, but once unwinding is implemented they'll start running all tests as well and we'll eventually start gating on them as well.

---

I'd love as many eyes on this as we've got as this was one of my first interactions with MSVC and Visual Studio, so there may be glaring holes that I'm missing here and there!

cc @retep998, @ricky26, @vadimcn, @klutzy 

r? @brson
2015-05-20 00:31:55 +00:00
Alex Crichton
b56d47cc80 mk: Enable building LLVM targeting MSVC
This commit modifies the makefiles to enable building LLVM with cmake and Visual
Studio to generate an LLVM that targets MSVC. Rust's configure script requires
cmake to be installed when targeting MSVC and will configure LLVM with cmake
instead of the normal `./configure` script LLVM provides. The build will then
run cmake to execute the build instead of the normal `make`.

Currently `make clean-llvm` isn't supported on MSVC as I can't figure out how to
run a "clean" target for the Visual Studio files.
2015-05-19 10:52:57 -07:00
Alex Crichton
7cf0b1798b configure: Start adding MSVC support
This commit starts to add MSVC support to the ./configure script to enable the
build system to detect and build an MSVC target with the cl.exe compiler and
toolchain. The primary change here is a large sanity check when an MSVC target
is requested (and currently only `x86_64-pc-windows-msvc` is recognized).

When building an MSVC target, the configure script either requires the
`--msvc-root` argument or for `cl.exe` to be in `PATH`. It also requires that if
in the path `cl.exe` is the 64-bit version of the compiler.

Once detected the configure script will run the `vcvarsall.bat` script provided
by Visual Studio to learn about the `INCLUDE` and `LIB` variables needed by the
`cl.exe` compiler to run (the default include/lib paths for the
compiler/linker). These variables are then reexported when running `make` to
ensure that our own compiles are running the same toolchain.

The purpose of this detection and environment variable scraping is to avoid
requiring the build itself to be run inside of a `cmd.exe` shell but rather
allow it to run in the currently expected MinGW/MSYS shell.
2015-05-19 10:52:55 -07:00
bors
e5394240a2 Auto merge of #25208 - lfairy:version-hash, r=brson
The code takes a prefix of the MD5 hash of the version string.

Since the hash command differs across GNU and BSD platforms, we scan for
the right one in the configure script.

Closes #25007
2015-05-14 00:42:32 +00:00
Ricky Taylor
315750ac92 Very hacky MSVC hacks.
Conflicts:
	mk/platform.mk
	src/librustc/session/config.rs
	src/librustc_back/target/aarch64_apple_ios.rs
	src/librustc_back/target/aarch64_linux_android.rs
	src/librustc_back/target/arm_linux_androideabi.rs
	src/librustc_back/target/arm_unknown_linux_gnueabi.rs
	src/librustc_back/target/arm_unknown_linux_gnueabihf.rs
	src/librustc_back/target/armv7_apple_ios.rs
	src/librustc_back/target/armv7s_apple_ios.rs
	src/librustc_back/target/i386_apple_ios.rs
	src/librustc_back/target/i686_apple_darwin.rs
	src/librustc_back/target/i686_pc_windows_gnu.rs
	src/librustc_back/target/i686_unknown_dragonfly.rs
	src/librustc_back/target/i686_unknown_linux_gnu.rs
	src/librustc_back/target/mips_unknown_linux_gnu.rs
	src/librustc_back/target/mipsel_unknown_linux_gnu.rs
	src/librustc_back/target/mod.rs
	src/librustc_back/target/powerpc_unknown_linux_gnu.rs
	src/librustc_back/target/x86_64_apple_darwin.rs
	src/librustc_back/target/x86_64_apple_ios.rs
	src/librustc_back/target/x86_64_pc_windows_gnu.rs
	src/librustc_back/target/x86_64_unknown_dragonfly.rs
	src/librustc_back/target/x86_64_unknown_freebsd.rs
	src/librustc_back/target/x86_64_unknown_linux_gnu.rs
	src/librustc_back/target/x86_64_unknown_openbsd.rs
	src/librustc_llvm/lib.rs
	src/librustc_trans/back/link.rs
	src/librustc_trans/trans/base.rs
	src/libstd/os.rs
	src/rustllvm/RustWrapper.cpp
2015-05-12 14:50:36 -07:00
bors
8c9dc18355 Auto merge of #24859 - richo:valgrind-tests, r=brson
This stung me more than once in dev.

Bonus DRY'ing up of configure that I did on my way past.
2015-05-09 02:07:18 +00:00
Chris Wong
939c53ea42 configure: display correct version for md5sum
The old code simply scanned for the first digit, then munched anything
after that. This didn't work for md5sum, as it would see the "5" and
treat "5sum" as the version instead.

This patch tweaks the algorithm so that it looks for a second
consecutive digit (or dot) after the first. Since "md5sum" has only one
digit, the new code skips over it as intended.
2015-05-08 22:52:02 +12:00
Chris Wong
535040aab8 Generate CFG_FILENAME_EXTRA from the version
The code takes a prefix of the MD5 hash of the version string.

Since the hash command differs across GNU and BSD platforms, we scan for
the right one in the configure script.

Closes #25007
2015-05-08 22:26:26 +12:00
Carol Nichols
468cb052b8 Expand OS X versions referenced in configure message
10.10 is out, so it's weird to see a message that says you're on 10.9.
Change the message to be >=10.9.
2015-05-07 19:35:58 -04:00
bors
2f613bfaeb Auto merge of #24902 - bombless:configure, r=pnkfelix
Closes #24840
2015-04-30 15:16:24 +00:00
York Xiang
98b7aaf3ef Mention --enable-optimize for --enable-debug 2015-04-30 21:39:52 +08:00
Felix S. Klock II
bd4b984537 add --enable-debuginfo-tests, analogous to --disable-optimize-tests.
Then, decouple the question of whether the compiler/stdlib carry
debuginfo (which is controlled via `--enable-debuginfo` and implied by
`--enable-debug`) from the question of whether the tests carry
debuginfo (which now no longer is implied by `--enable-debug` nor
`--enable-debuginfo`, and is off by default).
2015-04-29 17:18:44 +02:00
bors
cadc67e8fd Auto merge of #24777 - alexcrichton:musl, r=brson
These commits build on [some great work on reddit](http://www.reddit.com/r/rust/comments/33boew/weekend_experiment_link_rust_programs_against/) for adding MUSL support to the compiler. This goal of this PR is to enable a `--target x86_64-unknown-linux-musl` argument to the compiler to work A-OK. The outcome here is that there are 0 compile-time dependencies for a MUSL-targeting build *except for a linker*. Currently this also assumes that MUSL is being used for statically linked binaries so there is no support for dynamically linked binaries with MUSL.

MUSL support largely just entailed munging around with the linker and where libs are located, and the major highlights are:

* The entirety of `libc.a` is included in `liblibc.rlib` (statically included as an archive).
* The entirety of `libunwind.a` is included in `libstd.rlib` (like with liblibc).
* The target specification for MUSL passes a number of ... flavorful options! Each option is documented in the relevant commit.
* The entire test suite currently passes with MUSL as a target, except for:
  * Dynamic linking tests are all ignored as it's not supported with MUSL
  * Stack overflow detection is not working MUSL yet (I'm not sure why)
* There is a language change included in this PR to add a `target_env` `#[cfg]` directive. This is used to conditionally build code for only MUSL (or for linux distros not MUSL). I highly suspect that this will also be used by Windows to target MSVC instead of a MinGW-based toolchain.

To build a compiler targeting MUSL you need to follow these steps:

1. Clone the current MUSL repo from `git://git.musl-libc.org/musl`. Build this as usual and install it.
2. Clone and build LLVM's [libcxxabi](http://libcxxabi.llvm.org/) library. Only the `libunwind.a` artifact is needed. I have tried using upstream libunwind's source repo but I have not gotten unwinding to work with it unfortunately. Move `libunwind.a` adjacent to MUSL's `libc.a`
3. Configure a Rust checkout with `--target=x86_64-unknown-linux-musl --musl-root=$MUSL_ROOT` where `MUSL_ROOT` is where you installed MUSL in step 1.

I hope to improve building a copy of libunwind as it's still a little sketchy and difficult to do today, but other than that everything should "just work"! This PR is not intended to include 100% comprehensive support for MUSL, as future modifications will probably be necessary.
2015-04-28 20:12:59 +00:00
Richo Healey
fc7faafae7 configure: Fail iff valgrind is explicitly requested but not available 2015-04-27 23:54:30 -07:00
bors
da2276e293 Auto merge of #24835 - rprichard:rfail-full, r=alexcrichton
This commit gets `make check-stage1` working again after #24718.

cc @tamird

r? @alexcrichton
2015-04-28 05:37:48 +00:00
Alex Crichton
cd980b3bee mk: Add support for musl-based builds
This commit adds support to the makefiles, configuration script, and build
system to understand MUSL. This is broken up into a few parts:

* Any target of the form `*-musl` requires the `--musl-root` option to
  `./configure` which will indicate the root of the MUSL installation. It is
  also expected that there is a libunwind build inside of that installation
  built against that MUSL.

* Objects from MUSL are copied into the build tree for Rust to be statically
  linked into the appropriate Rust library.

* Objects for binary startup and shutdown are included in each Rust installation
  by default for MUSL. This requires MUSL to only be installed on the machine
  compiling rust. Only a linker will be necessary for compiling against MUSL on
  a target machine.

Eventually a MUSL and/or libunwind build may be integrated by default into the
build but for now they are just always assumed to exist externally.
2015-04-27 10:11:15 -07:00
Richo Healey
b982a751f4 configure: Disable valgrind-rpass if there's no valgrind 2015-04-27 01:04:22 -07:00
Richo Healey
a8ea78bc35 configure: generic run command 2015-04-27 00:58:31 -07:00
bors
314b1f16b7 Auto merge of #24679 - tamird:enable-debug, r=pnkfelix
r? @alexcrichton
2015-04-26 15:04:33 +00:00
Ryan Prichard
5e37729036 Add a new test group, rfail-full that runs rfail tests with fulldeps.
In most places in mk/tests.mk, it's positioned after rpass-full and
before cfail-full (because rfail comes before cfail). The order of tests
seems a little inconsistent, but reordering everywhere would obscure this
commit.
2015-04-26 06:05:38 -07:00
Brian Anderson
0c196fd44c configure: Fix CDPATH bug 2015-04-22 14:52:35 -07:00
Tamir Duberstein
98f4221d49 --enable-debug adds -g. Closes #7205 2015-04-22 07:16:38 -07:00
Tamir Duberstein
0f1bfda006 Alphabetize 2015-04-22 07:16:38 -07:00
Richo Healey
fd69ac160b configure: Turn optimization back on iff --enable-optimize 2015-04-14 00:58:57 -07:00
Richo Healey
87efd2cd74 configure: Set CFG_<FOO>_PROVIDED if it was supplied
This allows you to distinguish between an option that defaulted, and an
option selected by the user
2015-04-14 00:58:51 -07:00
Richo Healey
71a4ea56c2 configure: Don't disable optimizations when enabling debug
Optimization is now on by default. Closes #24405
2015-04-14 00:07:27 -07:00
bors
c897ac04e2 Auto merge of #24177 - alexcrichton:rustdoc, r=aturon
This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).

I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
2015-04-10 16:18:44 +00:00
Brian Anderson
0e0c841bd5 Nightly gets LLVM assertions 2015-04-09 11:51:46 -07:00
Brian Anderson
a725426ec8 Don't deoptimize llvm when --enable-debug
libLTO fails to link here.
2015-04-08 18:01:46 -07:00
Brian Anderson
6d17c35cd5 configure: Add --enable-debug-jemalloc 2015-04-08 15:12:08 -07:00
Brian Anderson
1002155c75 Add --enable-debug to control multiple perf options 2015-04-08 14:21:36 -07:00
Brian Anderson
7cbf823353 configure: Add --enable-debuginfo 2015-04-08 13:57:37 -07:00
Brian Anderson
8545d2ce53 configure: Disable LLVM asserts by default 2015-04-08 13:27:12 -07:00
Brian Anderson
2cdfd372e2 configure: Clarify help message for --enable-debug-assertions 2015-04-08 13:25:20 -07:00
Brian Anderson
59e332bd2f configure: Disable debug assertions by default 2015-04-08 13:23:44 -07:00
Brian Anderson
ed8eebd99b configure: Rename --enable-debug to --enable-debug-assertions 2015-04-08 13:22:56 -07:00
Brian Anderson
bc9f16c599 configure: Remove obsolete --disable-verify option
rust-installer never verifies.
2015-04-08 12:16:47 -07:00
Brian Anderson
45eb54c870 configure: Remove obsolete --nightly flag 2015-04-08 12:07:35 -07:00
Alex Crichton
10359de405 compiletest: Add support for running rustdoc tests
Add a new test directory called 'rustdoc' where all files inside are documented
and run against the `htmldocck` script to have assertions about the output.
2015-04-07 17:54:33 -07:00
Manish Goregaokar
3058eede7b Rollup merge of #23990 - dhuseby:bitrig_fixing_jemalloc_config, r=alexcrichton
Until I can figure out the correct way to configure jemalloc for Bitrig, this patch will correctly disable it.  All other build targets remain unchanged.
2015-04-04 10:54:58 +05:30
Dave Huseby
787c6cda00 this correctly disables jemalloc on Bitrig 2015-04-03 08:54:08 -07:00
Andrea Canciani
0621a83ba5 Workaround javac popup on MacOS X
MacOS X does not ship with Java installed by default. Instead it
includes binary stubs that upon execution pop up a message suggesting
the installation of the JDK.

Since `javac` is only used when `antlr4` is available, it is possible
to work around the popup by only probing for `javac` if `antlr4` has
been successfully detected (in which case the JDK is probably already
installed on the system).

Fixes #23138.
2015-04-03 15:10:59 +02:00
bors
14192d6df5 Auto merge of #23848 - cmr:no-compiler-docs, r=huonw
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want them.

(Crates behind the facade are not documented at all)

[breaking-change]
2015-03-30 11:35:52 +00:00
Corey Richardson
e64b677ca6 mk: don't build docs for internal or behind-the-facade crates in beta/stable
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want compiler docs during development.

Crates behind the facade are only documented on nightly/dev builds (where they
can be used).

[breaking-change]

Closes #23772
Closes #21297
2015-03-29 06:15:51 -04:00
Vadim Petrochenkov
1accaa9f86 Fix some typos 2015-03-28 18:09:51 +03:00
Brian Anderson
1aa75cea1d configure: Fix detection of 32-bit Linux userspace
The variable '$SHELL' is not actually defined by 'sh'.
2015-03-23 14:27:09 -07:00
Richo Healey
a0297cbe12 powerpc: Support configure on native ppc[64] hosts 2015-03-15 20:04:04 -07:00
Björn Steinbrink
bb18a3cfe7 Drop support for LLVM < 3.5 and fix compile errors with 3.5
LLVM older that 3.6 has a bug that cause assertions when compiling certain
constructs. For 3.5 there's still a chance that the bug might get fixed
in 3.5.2, so let's keep allowing to compile with it for it for now.
2015-03-14 13:14:04 +01:00
Dave Huseby
8e082f77cf disabling jemalloc on bitrig 2015-03-10 23:39:49 -07:00
Dave Huseby
d0ae7caa49 fixing configure so that it works on bitrig/openbsd 2015-03-09 16:25:50 -07:00
Chloe
9f28f7249f added support for CYGWIN 6.3 into configure script
Not checking for 32/64 bit, since `uname -s` no longer contains an indicator (and `uname -m` returns correct results)
2015-03-07 03:44:02 -05:00
bors
4d716decb5 Auto merge of #22474 - iKevinY:pandoc-version-check, r=brson
Executing `configure` seems to create the following error due to how the script [parses Pandoc's version](https://github.com/rust-lang/rust/blob/master/configure#L705):

```text
./configure: line 705: [: pandoc: integer expression expected
./configure: line 705: [: 1.12.4.2: integer expression expected
```

This issue seems to stem from a discrepancy between BSD and GNU versions of sed. This patch changes the sed command to use an extended regex, which works with both flavours of sed.
2015-03-06 19:04:53 +00:00
Kevin Yap
4349fa4756 Fix Pandoc version check in configure
Using an extended regex fixes pattern matching on BSD sed.
2015-03-02 22:49:33 -08:00
Björn Steinbrink
8b263f7566 Drop support for clang < 3.2
Fixes #20467
2015-02-28 17:53:12 +01:00
bors
2b01a37ec3 Auto merge of #21959 - dhuseby:bitrig-support, r=brson
This patch adds the necessary pieces to support rust on Bitrig https://bitrig.org
2015-02-21 09:20:48 +00:00
Florian Hahn
6824f1365d Add pfail targets for parse-fail tests 2015-02-16 20:52:39 +01:00
bors
95b228ab95 Auto merge of #22041 - semarie:configure-compat, r=alexcrichton
the sed option `--in-place` (or `-i`) is a GNU extension, and it is not
portable to BSD system (openbsd and freebsd checked).

use an alternate construction in order to keep the semantic.
2015-02-14 07:10:52 +00:00
Dave Huseby
34590d6def restore the clobber behavior during config 2015-02-11 14:49:09 -08:00
Dave Huseby
cd8f31759f bitrig integration 2015-02-11 14:49:06 -08:00
Björn Steinbrink
6e8b8733c9 Add a flag to skip the LLVM version check in configure
When trying to build against a newer, local LLVM version it might be
preferable to have a flag to disable the LLVM version check instead of
having to modify the configure script.

Fixes #21998
2015-02-10 16:31:46 +01:00
Sébastien Marie
04b7976c2f sed -i option isn't portable
the sed option `--in-place` (or `-i`) is a GNU extension, and it is not
portable to BSD system (openbsd and freebsd checked).

use an alternate construction in order to keep the semantic.
2015-02-07 08:55:37 +01:00
Steve Klabnik
7d4f068919 Only accept xelatex for building PDF docs
None of the others work, so let's remove them.

Fixes #17220.
2015-02-05 23:21:12 -05:00
Sébastien Marie
fcb30a0b67 openbsd support 2015-02-01 14:41:38 +01:00
bors
102ab57d80 Auto merge of #21582 - FlaPer87:rollup, r=brson
- Successful merges: #21108, #21445, #21498, #21504, #21532, #21535, #21539, #21540, #21541, #21550, #21560, #21573, #21579
- Failed merges:
2015-01-25 13:33:18 +00:00
bors
4e4e8cff16 Auto merge of #21452 - bleibig:bison-grammar, r=nikomatsakis
This adds a new lexer/parser combo for the entire Rust language can be generated with with flex and bison, taken from my project at https://github.com/bleibig/rust-grammar. There is also a testing script that runs the generated parser with all *.rs files in the repository (except for tests in compile-fail or ones that marked as "ignore-test" or "ignore-lexer-test"). If you have flex and bison installed, you can run these tests using the new "check-grammar" make target.

This does not depend on or interact with the existing testing code in the grammar, which only provides and tests a lexer specification.

OS X users should take note that the version of bison that comes with the Xcode toolchain (2.3) is too old to work with this grammar, they need to download and install version 3.0 or later.

The parser builds up an S-expression-based AST, which can be displayed by giving the "-v" argument to parser-lalr (normally it only gives output on error). It is only a rough approximation of what is parsed and doesn't capture every detail and nuance of the program.

Hopefully this should be sufficient for issue #2234, or at least a good starting point.
2015-01-24 22:14:14 +00:00
Flavio Percoco Premoli
8a2eee6095 Rollup merge of #21541 - steveklabnik:gh13179, r=huonw
Fixes #13179
2015-01-24 10:42:41 +01:00
Steve Klabnik
7aa3ed1ee8 Check for make in configure
Fixes #13179
2015-01-22 22:44:43 -05:00
Steve Klabnik
a80807028a Language tweak in configure
Fixes #13082
2015-01-22 22:35:28 -05:00
Alex Crichton
81504f211c rollup merge of #21413: ahmedcharles/remove-test-features
This isn't the entire set of changes, there are more coming. #19145
2015-01-21 09:15:57 -08:00
bors
6869645e86 Auto merge of #21242 - richo:no-perl, r=brson
There's only one build-critical path in which perl is used, and it was to do a text replacement trivially achievable with sed(1).

I ported the indenter script because it [appears to be used][indenter], but removed check links because it appears to be entirely out of date.

[indenter]: https://github.com/rust-lang/rust/blob/master/src/librustc/util/common.rs#L60-70
2015-01-21 11:07:31 +00:00
Brian Leibig
f39297f991 Add a LALR grammar for Rust with testing support 2015-01-20 18:47:17 -08:00
Ahmed Charles
d7b30f9c0a Remove ratchet-bench from configure. 2015-01-19 23:40:27 -08:00
Brian Anderson
3e38926ff4 configure: Use a more portable 'date' command to create the bootstrap key 2015-01-17 16:38:04 -08:00
Richo Healey
948dcaa72b Remove perl as a dependency 2015-01-16 08:49:54 -08:00
Richo Healey
31d232e204 powerpc: Add support to configure 2015-01-11 21:14:23 -08:00
Steve Klabnik
16a6ebd1f6 "The Rust Programming Language"
This pulls all of our long-form documentation into a single document,
nicknamed "the book" and formally titled "The Rust Programming
Language."

A few things motivated this change:

* People knew of The Guide, but not the individual Guides. This merges
  them together, helping discoverability.
* You can get all of Rust's longform documentation in one place, which
  is nice.
* We now have rustbook in-tree, which can generate this kind of
  documentation. While its style is basic, the general idea is much
  better: a table of contents on the left-hand side.
* Rather than a almost 10,000-line guide.md, there are now smaller files
  per section.
2015-01-08 12:02:11 -05:00
Brian Anderson
c27133e2ce Preliminary feature staging
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.

It has three primary user-visible effects:

* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.

Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.

Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.

Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.

The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).

Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).

This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint.  I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.

Closes #16678

[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
2015-01-07 15:34:56 -08:00
Akos Kiss
6e5fb8bd1b Initial version of AArch64 support.
Adds AArch64 knowledge to:
* configure,
* make files,
* sources,
* tests, and
* documentation.
2015-01-03 15:16:10 +00:00
Steve Klabnik
3cb10ef147 Remove mentions of sundown. 2014-12-11 16:36:11 -05:00
bors
3c89031e1f auto merge of #18613 : steveklabnik/rust/ownership_guide, r=huonw
This is a work in progress, but this should get *extensive* review, so I'm putting it up early and often.

This is the start of a draft of the new 'ownership guide,' which explains ownership, borrowing, etc. I'm feeling better about this framing than last time's, but we'll see.
2014-12-04 04:52:37 +00:00
Steve Klabnik
5a2048f7bb remove two unneccesary directories from configure 2014-12-02 09:21:28 -05:00
Steve Klabnik
e2fe7a083e Lifetime guide -> ownership guide 2014-11-26 15:03:12 -05:00
Steve Klabnik
ba9e02f862 remove the generation of grammar from the reference 2014-11-24 17:23:55 -05:00
Jakub Bukaj
69a217f37c rollup merge of #19239: jauhien/fix-libdir
A fix for a windows problem pointed by @retep998 in the PR #16552.
2014-11-23 14:12:03 -05:00
Jakub Bukaj
f90471e4e3 rollup merge of #19161: jmesmon/mk-fixes
This is a collection of misc issues I've run into while adding bindir & libdir support that aren't really bindir & libdir specific.

While I continue to fiddle with bindir and libdir bugs, I figured these might be useful for others to have merged.
2014-11-23 14:11:47 -05:00
Jauhien Piatlicki
6ffb7f0132 fix for PR#16552 implementation on windows: CFG_LIBDIR should be always set in configure variables 2014-11-23 15:36:42 +01:00
bors
2af82f7530 auto merge of #19117 : jmesmon/rust/mk-cfg-suffix, r=cmr
Right now we'll end up globbing them into the accepted targets and (ever worse) they will override the make variables of real target files because we `include`d everything in that directory.

As a side effect, editors get a better hint on file types.
2014-11-22 01:46:46 +00:00
bors
2fcbf90d68 auto merge of #16552 : jauhien/rust/fix-libdir, r=alexcrichton
Fixies #11671

This commit changes default relative libdir 'lib' to a relative libdir calculated using LIBDIR provided by --libdir configuration option. In case if no option was provided behavior does not change.
2014-11-21 06:21:48 +00:00
Cody P Schafer
9c320dd7af configure: silence warning about LOCAL_RUST_ROOT being set
We have a default value for this ('/usr/local'), so this warning is
printed ALL the time unless one does --enable-local-rust. As a result,
it doesn't really help at all.
2014-11-20 16:00:12 -05:00
Cody P Schafer
8581f00249 mk/cfg: add .mk suffix on files to avoid "supprises" when backup files (file~) are in the directory 2014-11-19 16:00:51 -05:00
Steve Klabnik
0e6d97aab2 New guide: error handling 2014-11-18 12:56:55 -05:00
Jauhien Piatlicki
e889f8091a Look for standard crates in LIBDIR provided by --libdir option,
not in hardcoded libdir path. If there was no LIBDIR provided
during configuration fallback to hardcoded paths.

Thanks to Jan Niklas Hasse for solution and to Alex Crichton for improvements.

Closes #11671
2014-11-16 01:01:11 +01:00
Vitali Haravy
c7a0b9c562 Do not put double quotes around empty variables. 2014-11-07 13:17:11 +00:00
Vitali Haravy
461945ee9e Correct building documenation with Pandoc and TeX on Windows. 2014-11-06 18:08:33 +03:00
Vitali Haravy
bec2ee77f7 Properly escape paths to executables. Fixes #18632. 2014-11-05 23:33:18 +00:00
Corey Richardson
6b130e3dd9 Implement flexible target specification
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.

iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.

The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.

The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.

A complete list of the targets we accept now:

arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf

i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu

mips-unknown-linux-gnu
mipsel-unknown-linux-gnu

x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu

Closes #16093

[breaking-change]
2014-11-04 05:07:47 -05:00
bors
3f37e2efac auto merge of #18192 : jmesmon/rust/platform-generic, r=alexcrichton
The goal here is to make it easier to add new platform definitions,
especially when the additions are programmatic (ie: in build scripts).
2014-10-28 05:46:53 +00:00
Alex Crichton
6f65ad1a44 rollup merge of #18251 : steveklabnik/build_module_guide 2014-10-27 12:53:02 -07:00
Felix S. Klock II
6f1e627388 config.mk: Added variants of valopt/opt that do not automatically putvar.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code.  When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.

----

As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully.  (If we cannot run
`rustc`, we really shouldn't try to keep going.)

----

Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.

----

Fix #17887.
2014-10-27 12:17:45 +01:00
Cody P Schafer
f3fd79d6aa split platform definitions out of mk/platform.mk
The goal here is to make it easier to add new platform definitions,
especially when the additions are programmatic (ie: in build scripts).
2014-10-25 21:01:18 -04:00
Steve Klabnik
0c3ad8be5b build the crates guide 2014-10-23 07:40:29 -04:00
Nick Cameron
80ff1d1a10 Error if we should be able to Valgrind but can't 2014-10-23 14:28:52 +13:00
Nick Cameron
f466e1a59f Add run-pass-valgrind tests
Closes #16914
2014-10-23 13:52:34 +13:00
Michael Woerister
895aac9935 debuginfo: Add LLDB version handling to test infrastructure. 2014-10-08 08:24:49 +02:00
bors
9a2286d3a1 auto merge of #16995 : kmcallister/rust/plugin-tutorial, r=alexcrichton
@steveklabnik, are you interested in looking this over?
2014-10-03 07:33:26 +00:00
Keegan McAllister
61bf75bb5e Add a guide to compiler plugins
Fixes #16983.
2014-10-01 13:21:52 -07:00
Aaron Turon
c5d2ed54a3 Remove libuv, gyp
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230)

[breaking-change]
2014-10-01 12:42:30 -07:00
Alex Crichton
94c1b1f30c rollup merge of #17544 : eklitzke/master 2014-09-29 08:12:32 -07:00
Alex Crichton
01c25e6c7b rollup merge of #17542 : brson/devchannel 2014-09-29 08:12:09 -07:00
bors
5079a10b1e auto merge of #17538 : brson/rust/winmk, r=alexcrichton 2014-09-29 12:43:13 +00:00
Evan Klitzke
29424ee219 fix a misspelling in the configure script 2014-09-25 16:40:10 -07:00
Brian Anderson
b5c17b3352 Use 'dev' for the release channel and version suffix when building from source
This is more consistent with how the other channels work.
2014-09-25 15:28:00 -07:00
Brian Anderson
b23c128ee0 configure: Fix the compatibility code for --enable-nightly
When --enable-nightly is not specified this expression is malformed
because $CFG_ENABLE_NIGHTLY is undefined.
2014-09-25 13:34:16 -07:00
Brian Anderson
12cb0bfcf4 Fix detection of win32 triple
This will hopefully fix the win32 nightlies.
2014-09-19 09:06:25 -07:00
Brian Anderson
48b5378b5a configure: Remove support for i686-pc-mingw32 triple 2014-09-18 11:49:03 -07:00
Alex Crichton
04c537ff56 rollup merge of #17285 : brson/relchan 2014-09-17 08:49:21 -07:00
Brian Anderson
a3c27ea3c6 mk: Update how the build deals with version labels. #16677
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.

--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.

Here's a summary of the affect of these values on version number and
artifact naming, respectively:

* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'

Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
2014-09-15 16:25:20 -07:00
Jonathan Boyett
53c3b83070 add missing semicolon to fix configure on darwin 2014-09-15 17:08:04 -04:00
Brian Anderson
1324a37795 Remove build system support for i686-pc-mingw32 triple in favor if i686-w64-mingw32 2014-09-12 10:46:31 -07:00
Dan Albert
8c3db5bc53 Allow Rust to be built with LLVM trunk (3.6). 2014-09-07 14:42:48 -07:00
Michael Woerister
849ae5d881 debuginfo: Emit different autotest debugger scripts depending on GDB version. 2014-08-27 15:19:14 +02:00
bors
36131f5be4 auto merge of #16691 : klutzy/rust/issue-15297, r=alexcrichton
First commit fixes issue regarding recognizing MSYS2 build.
Second commit fixes issue regarding MSYS/Windows paths.
2014-08-23 22:35:56 +00:00
klutzy
a3d77e616b configure: Recognize i686 build on msys2 2014-08-23 01:47:37 +09:00
Jauhien Piatlicki
70ea0bb5f5 Fix LLVM version in configure
Upstream LLVM from VCS already has version 3.6,
configure fixed appropriately to allow building with it
2014-08-22 00:39:18 +02:00
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