about summary refs log tree commit diff
path: root/src/etc/maketest.py
AgeCommit message (Collapse)AuthorLines
2016-04-28test: Move run-make tests into compiletestAlex Crichton-96/+0
Forcing them to be embedded in makefiles precludes being able to run them in rustbuild, and adding them to compiletest gives us a great way to leverage future enhancements to our "all encompassing test suite runner" as well as just moving more things into Rust. All tests are still Makefile-based in the sense that they rely on `make` being available to run them, but there's no longer any Makefile-trickery to run them and rustbuild can now run them out of the box as well.
2016-02-16pass CXX to run-makeSébastien Marie-0/+1
use CXX value found at configure time inside run-make tests. it permits OpenBSD to pass llvm-module-pass test (which use CXX variable).
2016-02-13Add LLVM ModulePass regression test using run-make.Corey Farwell-0/+2
Part of #31185
2015-12-13Better support for `--llvm-root`.Richard Diamond-0/+2
This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
2015-09-17rmake: Get all tests passing on MSVCAlex Crichton-2/+10
2015-08-11trans: Re-enable unwinding on 64-bit MSVCAlex Crichton-8/+8
This commit leverages the runtime support for DWARF exception info added in #27210 to enable unwinding by default on 64-bit MSVC. This also additionally adds a few minor fixes here and there in the test harness and such to get `make check` entirely passing on 64-bit MSVC: * The invocation of `maketest.py` now works with spaces/quotes in CC * debuginfo tests are disabled on MSVC * A link error for librustc was hacked around (see #27438)
2015-01-27Fix PEP8 in maketestRicho Healey-18/+20
2015-01-18tests: Add htmldocck.py script for the use of Rustdoc tests.Kang Seonghoon-0/+2
The script is intended as a tool for doing every sort of verifications amenable to Rustdoc's HTML output. For example, link checkers would go to this script. It already parses HTML into a document tree form (with a slight caveat), so future tests can make use of it. As an example, relevant `rustdoc-*` run-make tests have been updated to use `htmldocck.py` and got their `verify.sh` removed. In the future they may go to a dedicated directory with htmldocck running by default. The detailed explanation of test scripts is provided as a docstring of htmldocck. cc #19723
2014-08-23test: Convert Window path to MSYS pathklutzy-3/+4
When MSYS shell executes program, if its arguments look like MSYS paths, MSYS automatically converts them into Windows paths. For example, `/c/path:/d/path` becomes `C:\path;D:\path`. However, if there is only one path e.g. `/c/path`, it becomes `C:/path`. maketest.py reverts the behavior to reduce confusion between MSYS and Windows, but it didn't handle the `/c/path` case. This patch fixes the issue. Fixes #15297 Fixes #15250
2014-05-18Refactoring: Introduce distinct host and target rpath var setters.Felix S. Klock II-7/+8
Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
2014-04-28test: Fix run-make on windowsklutzy-10/+37
2014-04-06mk: Pass the name of the make command to maketest.pyBrian Anderson-7/+8
This should make BSD use the proper GNU make.
2014-04-06Remove check-fast. Closes #4193, #8844, #6330, #7416Brian Anderson-0/+5
2014-02-21mk: Get "make check" passing with --disable-rpathAlex Crichton-0/+3
This involves passing through LD_LIBRARY_PATH through more places, specifically in the compiletest, run-make, and doctest runners.
2014-02-05etc: add missing license boilerplatesAdrien Tétar-1/+9
2014-01-03Change rmake and doc-test to support TESTNAMEAlex Crichton-0/+5
Closes #11288 Closes #11222
2013-12-18Add a rustdoc testCorey Richardson-0/+1
This is just a smoke test which verifies that the expected files are generated. Also makes the rmake tests have the right deps.
2013-11-30Test fixes and merge conflictsAlex Crichton-0/+1
2013-11-29Add a new run-make test directoryAlex Crichton-0/+26
This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434