This modifies the command-line usage of rustdoc to intake its own JSON output as
well as a rust source file. This also alters the command line from
`rustdoc input file` to `rustdoc file` with the input/output formats specified
as -r and -w, respectively.
When using a JSON input, no passes or plugins are re-run over the json, instead
the output is generated directly from the JSON that was provided. Passes and
plugins are still run on rust source input, however.
This change adds -Z soft-float option for generating
software floating point library calls.
It also implies using soft float ABI, that is the same as llc.
It is useful for targets that have no FPU.
They're getting smaller each time though!
The highlight of this round is source files in documentation. Still trying to figure out the best syntax-highlighting solution.
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
Three things in this commit:
1. Actually build the rustpkg tutorial. I didn't know I needed this when
I first wrote it.
2. Link to it rather than the manual from the
tutorial.
3. Update the headers: most of them were one level too deeply
nested.
Removes old rustdoc, moves rustdoc_ng into its place instead (plus drops the _ng
suffix). Also shreds all reference to rustdoc_ng from the Makefile rules.
This large commit implements and `html` output option for rustdoc_ng. The
executable has been altered to be invoked as "rustdoc_ng html <crate>" and
it will dump everything into the local "doc" directory. JSON can still be
generated by changing 'html' to 'json'.
This also fixes a number of bugs in rustdoc_ng relating to comment stripping,
along with some other various issues that I found along the way.
The `make doc` command has been altered to generate the new documentation into
the `doc/ng/$(CRATE)` directories.
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
Because less C++ is better C++!
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
This patch fixes some errors of MIPS target, however, MIPS C ABI is still broken. I will send another PR to fix the problem.
Because MIPS target has no "generic" CPU name, I add --target-cpu and --target-feature to RUST_FLAGS. In order to workaround the "compact frame descriptions incompatible with DWARF2 .eh_frame" problem, the linker I used is CXX but not CC.
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
Note that some `rustdoc_ng` tests were removed, but @cmr says they weren't supposed to be there in the first place. The rustdoc_ng code should also be included in `make install` and `make dist` now.
This works by adding this directory to GCC include search path before mingw system headers directories,
so we can intercept their inclusions and add missing definitions without having to modify files in mingw/include.
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
This is a reopening of the libuv-upgrade part of #8645. Hopefully this won't
cause random segfaults all over the place. The windows regression in testing
should also be fixed (it shouldn't build the whole compiler twice).
A notable difference from before is that gyp is now a git submodule instead of
always git-cloned at make time. This allows bundling for releases more easily.
Closes#8850
The new glob tests created tmp/glob-tests as a directory, but the never removed
it. The `make clean` target then attempted to `rm -f` on this, but it couldn't
remove the directory. This both changes the clean target to `rm -rf` tmp files,
and also alters the tests to delete the directory that all the files are added
into.
This should make benchmarks easier to understand. But, it doesn't work.
BENCH_RS in mk/tests.mk has everything, from what I can tell in remake, but
only those that are direct children of src/test/bench get build and run.
@graydon, can you lend your expertise? I can't make heads or tails of this
makefile.
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.
This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"
Closes#8826
The syntax of the script requires python < 3, and so does our build system so we
can just use CFG_PYTHON to run the script. This prevents build failures where
`python` is actually python3 or later.
There were two main differences with the old libuv and the master version:
1. The uv_last_error function is now gone. The error code returned by each
function is the "last error" so now a UvError is just a wrapper around a
c_int.
2. The repo no longer includes a makefile, and the build system has change.
According to the build directions on joyent/libuv, this now downloads a `gyp`
program into the `libuv/build` directory and builds using that. This
shouldn't add any dependences on autotools or anything like that.
Closes#8407Closes#6567Closes#6315
This makes it relatively easy for us to split testsuite load between machines in buildbot. I've added buildbot-side support for setting up builders with -a.b suffixes (eg. linux-64-opt-vg-0.5, linux-64-opt-vg-1.5, linux-64-opt-vg-2.5, linux-64-opt-vg-3.5, linux-64-opt-vg-4.5 causes the valgrind-supervised testsuite to split 5 ways across hosts).
We currently have no need for the frame pointers on any platform. They
may eventually be needed on platforms without an equivalent to the DWARF
call frame information to walk the stack in the garbage collector.
Closes#7477
`stdtest` and `extratest` expects to be able to write to `tmp` directory under the current working directory, so the first commit creates `tmp` directory and changes the directory before running tests.
The second commit adds `--bench` argument to test runs and copies metrics from the remote device.
r? @graydon Also, notably, make rustpkgtest depend on the rustpkg executable (otherwise, tests that shell out to rustpgk might run when rustpkg doesn't exist).
Get rid of special cases for names beginning with "rust-" or
containing hyphens, and just store a Path in a package ID. The Rust-identifier
for the crate is none of rustpkg's business.
This commit allows you to write:
extern mod x = "a/b/c";
which means rustc will search in the RUST_PATH for a package with
ID a/b/c, and bind it to the name `x` if it's found.
Incidentally, move get_relative_to from back::rpath into std::path
r? anyone
Fix#8057
This commit fixes some oversights in the Makefile where rustc could be
invoked without some of its dependencies yet in place. (I encountered
the problem in practice; its not just theoretical.)
As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one
writes an invocation of rustc where $(1) is the stage number $(2) is
the target triple $(3) is the host triple. (Other uses of the macro
may plug in actual values or different parameters in for those three
formal parameters.)
When you have invocations of $(STAGE...), you need to make sure that
its dependences are satisfied; otherwise, if someone is using `make
-jN` for certain (large-ish) `N`, one can encounter situations where
GNU make attempts to invoke `rustc` before it has actually copied some
of its libraries into place, such as libmorestack.a, which causes a
link failure when the rustc invocation attempts to link in those
libraries.
In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3),
which is described in Makefile.in as "Prerequisites for using the
stageN compiler to build target artifacts"
----
In addition to adding the extra dependences on TSREQ..., I also
replaced occurrences of the pattern:
TSREQ$(1)_T_$(2)_H_$(3)
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2))
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2))
with:
SREQ$(1)_T_$(2)_H_$(3)
which is equivalent to the above, as defined in Makefile.in
----
Finally, for the cases where TSREQ was missing in tests.mk, I went
ahead and put in a dependence on SREQ rather than just TSREQ, since it
was not clear to me how one could expect to compile those cases
without stdlib and extralib.
(It could well be that I should have gone ahead and done the same in
other cases where I saw TSREQ was missing, and put SREQ in those
cases as well. But this seemed like a good measure for now, without
needing to tax my understanding of the overall makefile
infrastructure much further.)
Remove directive, if present, from CFG_RUSTC_FLAGS.
Fix#7898.
(One alternative tack is to build up distinct CFG_TEST_RUSTC_FLAGS
alongside CFG_RUSTC_FLAGS; but currently debug is the only --cfg flag
ever added to CFG_RUSTC_FLAGS; the other contents of CFG_RUSTC_FLAGS
are a mix of -Z flags and a few other switches like O, which seem to
make sense to propogate to the tests.)
This should get us over the hump of activating basic ratcheting on codegen tests, at least. It also puts in place optional (disabled by default) ratcheting on all #[bench] tests, and records all metrics from them to harvestable .json files in any case.
This commit fixes some oversights in the Makefile where rustc could be
invoked without some of its dependencies yet in place. (I encountered
the problem in practice; its not just theoretical.)
As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one
writes an invocation of rustc where $(1) is the stage number $(2) is
the target triple $(3) is the host triple. (Other uses of the macro
may plug in actual values or different parameters in for those three
formal parameters.)
When you have invocations of $(STAGE...), you need to make sure that
its dependences are satisfied; otherwise, if someone is using `make
-jN` for certain (large-ish) `N`, one can encounter situations where
GNU make attempts to invoke `rustc` before it has actually copied some
of its libraries into place, such as libmorestack.a, which causes a
link failure when the rustc invocation attempts to link in those
libraries.
In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3),
which is described in Makefile.in as "Prerequisites for using the
stageN compiler to build target artifacts"
----
In addition to adding the extra dependences on TSREQ..., I also
replaced occurrences of the pattern:
TSREQ$(1)_T_$(2)_H_$(3)
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2))
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2))
with:
SREQ$(1)_T_$(2)_H_$(3)
which is equivalent to the above, as defined in Makefile.in
----
Finally, for the cases where TSREQ was missing in tests.mk, I went
ahead and put in a dependence on SREQ rather than just TSREQ, since it
was not clear to me how one could expect to compile those cases
without stdlib and extralib.
(It could well be that I should have gone ahead and done the same in
other cases where I saw TSREQ was missing, and put SREQ in those
cases as well. But this seemed like a good measure for now, without
needing to tax my understanding of the overall makefile
infrastructure much further.)
When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)
When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.
The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.
Fixes#3225 (at least in terms of mitigating the multiple library
problem by proactively warning the user about it.)
This is a small follow-up fix to the previous commit: I needed
to quote the right-hand side of the definition for the variable
MATCHES, to handle the case where there are more than one previously
installed libraries in the target directory.
Namely, switched in many places to using GNU make provided functions
for directory listing and text processing, rather than spawning a
shell process to do that work.
In the process of the revision, learned about Target-specific
variables, which were very applicable to INSTALL_LIB (which, on a
per-recipe basis, was always receiving the same actual arguments for
its first two formal parameters in every invocation).
http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html
(We might be able to make use of those in future refactorings.)
----
Also adds a cleanup pass to get-snapshot.py as well, since the same
problem arises when we unpack libraries from the snapshot archive into
a build directory with a prior snapshot's artifacts. (I put this step
into the python script rather than the makefile because I wanted to
delay the cleanup pass until after we have at least successfully
downloaded the tarball. That way, if the download fails, you should
not destroy the previous unarchived snapshot libraries and build
products.)
----
Also reverted whitespace changes to minimize diff.
I plan to put them back in in a dedicated commit elsewhere.
As per https://mail.mozilla.org/pipermail/rust-dev/2013-July/004685.html
This is the initial machinery to setup the l10n infrastructure for markdown documentation.
A new "docs-l10n" target will take care of generating, updating and then building .pot and .po files, and later on the final .md.
This commit includes the .pot for all current .md docs; they can be feed directly to Mozilla Verbatim if wanted.
Please note that po4a only provides the orig.md -> .pot -> l10n.po -> l10n.md flow. The l10n.md -> l10n.html generation is not currently built in the makefile, as no language has been enabled.
This commit add a new "docs-l10n" make target which uses po4a to:
* create .pot (PO templates) from markdown doc
* update templates and po for enabled languages
* generate translated markdown for completed (> 80%) translations
Currently, no language has been activated.
Signed-off-by: Luca Bruno <lucab@debian.org>
When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)
When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.
The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.
This makes it possible for us to trigger the llvm-clean make-target by checking in a change that touches rustllvm/llvm-auto-clean-stamp. Most developers don't need to see or know about this, but when you push a change that "needs an LLVM rebuild", even if not otherwise obvious, this should give a mechanism to do it.
- Fix stat struct for Android (found by SEGV at run-pass/stat.rs)
- Adjust some test cases to rpass for Android
- Modify some script to rpass for Android
