| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit deletes the old build system located in the `mk` folder as it's now
been obsoleted for two cycles and is replaced by rustbuild.
|
|
|
|
(They were added to `ctags.mk` in PR #33256, but I guess I must have
only tested running `make TAGS.emacs TAGS.rustc.emacs` and not `make
TAGS.rustc.emacs` on its own.)
|
|
add documentation on howto build just rustc without libstd to the build system
I searched for days until I found this, maybe this helps other poor souls :joy:
for reference #33990
|
|
|
|
|
|
Improve help for make command
r? @steveklabnik
|
|
Add examples for "make help" command
|
|
Also removes mention of tidy.py from the tidy sources.
|
|
This commit removes all infrastructure from the repository for our so-called
snapshots to instead bootstrap the compiler from stable releases. Bootstrapping
from a previously stable release is a long-desired feature of distros because
they're not fans of downloading binary stage0 blobs from us. Additionally, this
makes our own CI easier as we can decommission all of the snapshot builders and
start having a regular cadence to when we update the stage0 compiler.
A new `src/etc/get-stage0.py` script was added which shares some code with
`src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists
the current stage0 compiler as well as cargo that we bootstrap from. This script
will download the relevant `rustc` package an unpack it into `$target/stage0` as
we do today.
One problem of bootstrapping from stable releases is that we're not able to
compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd).
To overcome this we employ two strategies:
* The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt`
(enabled as a result of #32731) and exported by the build system. This enables
nightly features in the compiler we download.
* The standard library and compiler are pinned to a specific stage0, which
doesn't change, so we're guaranteed that we'll continue compiling as we start
from a known fixed source.
The process for making a release will also need to be tweaked now to continue to
cadence of bootstrapping from the previous release. This process looks like:
1. Merge `beta` to `stable`
2. Produce a new stable compiler.
3. Change `master` to bootstrap from this new stable compiler.
4. Merge `master` to `beta`
5. Produce a new beta compiler
6. Change `master` to bootstrap from this new beta compiler.
Step 3 above should involve very few changes as `master` was previously
bootstrapping from `beta` which is the same as `stable` at that point in time.
Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and
get to use new features. This also shouldn't slow the release too much as steps
1-5 requires little work other than waiting and step 6 just needs to happen at
some point during a release cycle, it's not time sensitive.
Closes #29555
Closes #29557
|
|
|
|
I don't believe these have been used at all recently, and I doubt many of them
still work, so remove the stale support.
|
|
Repertory is a real world, but it doesn't really make sense in that context.
|
|
|
|
|
|
|
|
Looks like cl.exe doesn't support this and we're also barely using them anyway
as we have very few header files and C code in general.
|
|
|
|
Also add docs because not being able to discover these things is the
pits.
|
|
The wiki doesn't seem to exist
|
|
We don't use 'task' anymore, these are now threads.
Because this changes the name of a compiler option, this is
[breaking-change]
|
|
|
|
|
|
Fixes #17950
|
|
|
|
|
|
The performance hit from these checks is significant, but unoptimized
builds are already incredibly slow. Enabling these checks results in
better test coverage since there are bots doing unoptimized builds, and
the cost is relatively small in the context of an unoptimized build.
This also allows using `JEMALLOC_FLAGS` to override the default
configure flags.
|
|
|
|
|
|
|
|
The current suite of benchmarks for the standard distribution take a significant
amount of time to run, but it's unclear whether we're gaining any benefit from
running them. Some specific pain points:
* No one is looking at the data generated by the benchmarks. We have no graphs
or analysis of what's happening, so all the data is largely being cast into
the void.
* No benchmark has ever uncovered a bug, they have always run successfully.
* Benchmarks not only take a significant amount of time to run, but also take a
significant amount of time to compile. I don't think we should mitigate this
for now because it's useful to ensure that they do indeed still compile.
This commit disables --bench test runs by default as part of `make check`,
flipping the NO_BENCH environment variable to a PLEASE_BENCH variable which will
manually enable benchmarking. If and when a dedicated bot is set up for
benchmarking, this flag can be enabled on that bot.
|
|
The previous dependency calculation was based on an arbitrary set of asterisks
at an arbitrary depth, but using the recursive version should be much more
robust in figuring out what's dependent.
|
|
This reverts commit d62163188a21e5afc3d0f476eaf7856d91f715b2.
Conflicts:
mk/install.mk
|
|
The previous dependency calculation was based on an arbitrary set of asterisks
at an arbitrary depth, but using the recursive version should be much more
robust in figuring out what's dependent.
Closes #13118
|
|
|
|
The tag marks were missing, and `make tips` didn't work.
|
|
|
|
This is a slightly more generic rewrite of install.mk. Currently
used for nothing, but we'll base all the binary distributables off it.
|
|
|
|
|
|
|
|
|
|
Because the build system treats Makefile.in and the .mk files slightly
differently (.in is copied, .mk are included), this makes the system
more uniform. Fewer build system changes will require a complete
reconfigure.
|
|
This way of doing snapshots hasn't been used since 2011.
|
|
'make help' is implemented in a fairly ridiculous way, using awk
to parse comments out of Makefile.in and displaying them.
|
|
|
|
|
|
This is blocking a snapshot because the stage0 target compiler comes from a
stage1 host compiler. This means that the stage0 compiler doesn't actually
understand the -Z prefer-dynamic flag and is dying as a result.
This will get added back to stage0 after a snapshot.
|
|
|
|
Move them all behind a new -C switch. This migrates some -Z flags and some
top-level flags behind this -C codegen option.
The -C flag takes values of the form "-C name=value" where the "=value" is
optional for some flags.
Flags affected:
* --llvm-args => -C llvm-args
* --passes => -C passes
* --ar => -C ar
* --linker => -C linker
* --link-args => -C link-args
* --target-cpu => -C target-cpu
* --target-feature => -C target-fature
* --android-cross-path => -C android-cross-path
* --save-temps => -C save-temps
* --no-rpath => -C no-rpath
* -Z no-prepopulate => -C no-prepopulate-passes
* -Z no-vectorize-loops => -C no-vectorize-loops
* -Z no-vectorize-slp => -C no-vectorize-slp
* -Z soft-float => -C soft-float
* -Z gen-crate-map => -C gen-crate-map
* -Z prefer-dynamic => -C prefer-dynamic
* -Z no-integrated-as => -C no-integrated-as
As a bonus, this also promotes the -Z extra-debug-info flag to a first class -g
or --debuginfo flag.
* -Z debug-info => removed
* -Z extra-debug-info => -g or --debuginfo
Closes #9770
Closes #12000
|
