02925447bd
This is a major refactor of Lake's build code. The key changes: * **Job Registration**: Significant build jobs are now registered by build functions. The DSL inserts this registration automatically into user-defined targets and facets, so this change should require no end-user adaption. Registered jobs are incrementally awaited by the main build function and the progress counter now indicates how many of these jobs are completed and left-to-await. On the positive side, this means the counter is now always accurate. On the negative side, this means that jobs are displayed even if they are no-ops (i.e., if the target is already up-to-date). * **Log Retention**: Logs are now part of a Lake monad's state instead of being eagerly printed. As a result, build jobs retain their logs. Using this change, logs are are now always printed after their associated caption (e.g., `[X/Y] Building Foo`) and are not arbitrarily interleaved with the output of other jobs. * **Simplify the build monad stack**: Previously, there was a lot of confused mixing between the various build monads in the codebase (i.e., `JobM`, `ScedulerM`, `BuildM`, `RecBuildM`, and `IndexBuildM` ). This refactor attempts to make there use more consistent and straightforward: * `FetchM` (formerly `IndexBuildM`) is the top-level build monad used by targets and facets and is now uniformly used in the codebase for all top-level build functions. * `JobM` is the monad of asynchronous build jobs. It is more limited than `FetchM` due to the fact that the build cache can not be modified asynchronously. * `SpawnM` (formerly `SchedulerM`) is the monad used to spawn build jobs. It lifts into `FetchM`. * `RecBuildM` and `CoreBuildM` (formerly `BuildM`) have been relegated to internal details of how `FetchM` / `JobM` are implemented / run and are no longer used outside of that context. * **Pretty progress.** Build progress (e.g., `[X/Y] Building Foo`) is now updated on a single line via ANSI escape sequences when Lake is outputting to a terminal. Redirected Lake output still sees progress on separate lines. * **Warnings-as-error option.** Adds a `--wfail` option to Lake that will cause a build to fail if Lake logs any warnings doing a build. Unlike some systems, this does not convert warnings into errors and it does not abort jobs which log warnings. Instead, only the top-level build fails. * **Build log cache.** Logs from builds are now cached to a file and replayed when the build is revisited. For example, this means multiple runs of a `--wfail` Lean build (without changes) will still produce the same warnings even though there is now an up-to-date `.olean` for the module. Closes #2349. Closes #2764.
33 lines
1 KiB
Bash
Executable file
33 lines
1 KiB
Bash
Executable file
#!/usr/bin/env bash
|
|
|
|
# We need a package test because we need multiple files with imports.
|
|
# Currently the other package tests all succeed,
|
|
# but here we need to check for a particular error message.
|
|
# This is just an ad-hoc text mangling script to extract the error message
|
|
# and account for some OS differences.
|
|
# Ideally there would be a more principled testing framework
|
|
# that took care of all this!
|
|
|
|
rm -rf .lake/build
|
|
|
|
# Function to process the output
|
|
verify_output() {
|
|
# Normalize path separators from backslashes to forward slashes
|
|
sed 's#\\#/#g' |
|
|
awk '/error: .*lean:/, /error: Lean exited/' |
|
|
sed '/error: Lean exited/d'
|
|
}
|
|
|
|
lake build 2>&1 | verify_output > produced.txt
|
|
|
|
# Compare the actual output with the expected output
|
|
if diff --strip-trailing-cr -q produced.txt expected.txt > /dev/null; then
|
|
echo "Output matches expected output."
|
|
rm produced.txt
|
|
exit 0
|
|
else
|
|
echo "Output differs from expected output:"
|
|
diff --strip-trailing-cr produced.txt expected.txt
|
|
rm produced.txt
|
|
exit 1
|
|
fi
|