generate metadata/hash on libraries.
remove -doc subpackage too, as it has different files depending the
arch.
with that, we should be able to have rustc on more archs.
OK sthen@
generated.
in general case, the output of `rustc -vV` is still used as part of the
hashed data. the output contains the exact version of the rustc and the
LLVM version used.
but when used for build the port, it will use a less changing string:
only the major+minor version (without patch number) and no more LLVM
version.
the choice between the two way is based on the presence of environment
variable.
it will permit to avoid change in filenames (and so PLIST regeneration
requirement) when:
- patch release of rustc is pushed
- llvm is updated
Version 1.31.1 (2018-12-20)
- Fix Rust failing to build on powerpc-unknown-netbsd
- Fix broken go-to-definition in RLS
- Fix infinite loop on hover in RLS
Cf https://blog.rust-lang.org/2018/05/10/Rust-1.26.html
- add arm64 support, tested by phessler@
- respect MAKE_JOBS again
- use lld on i386 to support 128 bits integers
- cleanup old patches
- only build what we actually package
- to keep RUST_BACKTRACE=1 enabled during build, properly separate
MAKE_ENV and TEST_ENV, by introducing a TEST_BIN variable used to
launch rustbuild with TEST_ENV (some tests are failing if RUST_BACKTRACE
is enabled).
- remove llvm-6 backported patches. this version of rustc has full
support of it. Hashes in library names will change when ports llvm
is upgraded, so PLIST will have to be regenerated.
- backport #49140 to be able to run "make test" without installing rustc
Backports some patches for LLVM6 compatibility.
Note that this is likely to be BROKEN-i386 soonish, i'm giving it a last
chance locally but i never managed to build it here. That also means we
can say goodbye to firefox on i386.
full changelog at https://blog.rust-lang.org/2017/11/22/Rust-1.22.html
port changes:
- switch to clang and libc++ (instead of egcc and estdc++)
- use devel/llvm instead of the embedded llvm version
- make i386 produce code for 'pentiumpro' instead of 'pentium4' so that
ppl can use ripgrep on pentium II's (yay!)
- use a hack (codegen-units=16) to fix memory pressure issues on i386.
Might not work forever.....
tested on i386 & amd64, went into an i386 bulk.
all the hard work from semarie@
clang/rust finds it when linking some rust code - somewhat needed by
stylo (the css engine written in rust within mozilla). Modeled after
what is done in lang/g77.
From semarie@, who discussed it with espie@.
- switch to rustbuild build system instead of configure (the world
definitely needed one more build system!)
- the build still takes +INF hours, this is being investigated
Note that rust will be a hard-requirement for gecko 54... sigh.
Tested by semarie@ and myself on i386 & amd64.
All the hard work and countless build hours by semarie@, thanks!
- changes in Makefile to make it compute itself the RUST_HASH value
- use new configure option --disable-codegen-tests as with don't have FileCheck
(from llvm) binary. remove the patches in configure and src/compiletest/runtest.rs
- disable (for now) two news tests added with unix socket support, that doesn't
pass. I will investigate them later.
- disable run-pass/backtrace test. The support of libbacktrace has been remove
recently.
- std::env::current_exe() returns an error instead of returning wrong
pathname (no complete, but rust build scripts makes (bad)
assumptions that I couldn't patch for now).
- rustc / rustdoc to use CFG_PREFIX (configure --prefix value) when
std::env::current_exe() return an error
- remove the installed wrapper used to pass --sysroot argument to
rustc (the wrapper was used for workaround the problem differently
for rustc, but didn't resolv the problem for rustdoc as it doesn't
have --sysroot argument).
looks ok edd@
- remove now unneeded MAKE_ENV option to pass --sysroot argument to bootstrapper
- backport the latest changes for building rustc under openbsd
- switch the install from installing a stage3 rustc binary to installing a stage2 rustc binary (and all required libraries)
ok juanfra@
