Considering that we break integration tests and revert commits frequently, it is better to run short integration tests on PR CI to catch test failures in integration tests. This commit changes to run short integration tests on every pull requests.
Run the integration tests on one configuration (of the nightly matrix) on each
push to main. Should catch 95% of integration test breakages. Useful for
identifying the particular offending commit and emailing the commit author.
This allows users to `pip install lib/Bindings/Python`. Similarly,
this supports `pip wheel lib/Bindings/Python`. The script generally
follows https://github.com/llvm/torch-mlir/pull/256, with some tweaks
that are specific to CIRCT's CMake choices (e.g. using an external
projects unified build).
This is required by the yapf tool we use to enforce formatting. Switch
back to using bash syntax for this check. Also re-format a few spots
that slipped in while the check was broken. Fixes#1162.
Different build configurations were previously trampling on the same
cache directory on the build host. The cache directory wasn't
configurable, so just use the cache action directly.
This way, the dev who pushed (or merged the PR) gets a notification if they
broke the build. Also makes it easier to figure out which commit broke the
build.
Doing this now since I'm might start caring about Windows builds soon. Running
it on push to main only (instead of also on PRs) since most code changes don't
break it, so it's kinda wasteful.
This is mostly mechanical for us. Some notable changes:
* Require a unified build for Python in CMake, docs, and CI
* New CMake defaults for some variables in CMakeLists.txt
* Use the new CMake functions for Python bindings and PyCDE
* Update imports for generated Python and Python extension libraries
* Update PYTHONPATH to reflect the new location under unified builds
When we switched to using docker for our PR builds, the default shell
changed from `bash` to `sh`. This change makes the workflow file
`sh` compatible.
* Use the `Python3_EXECUTABLE` found by CMake itself (alongside the libs
and includes) to execute integration tests. This should no longer
require explicitly specifying a python executable in most cases. Where
needed, users can always override `Python3_EXECUTABLE`.
* Add `capnp` requirement on ESI tests. Otherwise the test fails on
systems that build the Python bindings but have no capnp.
* Add some guidance for users that are mainly interested in the Python
bindings of CIRCT. Fixes#1072.
The intent of the check was to only run yapf on the files that
changed, but if no Python files changed, the grep command returns 1
and fails the check. In that case, return an empty list of files, and
check for that before running yapf.
Bumping LLVM to get llvm/llvm-project@0126e90. Updating the workflow since there's no reason to cache the LLVM source code. Doing both simultaneously to save compilation resources.
This adds a -shared-libs option to llhd-sim that is analogous to the
same option for mlir-cpu-runner. If specified, those libraries are
passed to the ExecutionEngine to dynamically load and link.
The `ubuntu-latest` tag is starting to point to Ubuntu 20.04, and this seemed to be causing issues related to finding `llvm-lit`. Stick to Ubuntu 18.04 explicitly for now.
This is the first step towards #710. This should be the minimal amount
of boilerplate to set up a Python module such that we can write
`import circt`. Note that this module does not actually bind to or
expose any API at the moment; this is just the boilerplate, and that
will follow.
The setup here is based on both the upstream MLIR Python bindings, as
well as what NPComp does.
This change adds a GCC build to the buildAndTest job which is run on
every PR. This step takes about 1m 30s to complete.
This also combines the two clang builds, in release and debug mode, into
a single build, release+asserts. Normally, a cmake release build adds
-DNDEBUG to all command line options. The LLVM cmake system has a flag
to override this, LLVM_ENABLE_ASSERTIONS. Building in release mode with
assertions should give us the best of both worlds for error checking.
The GCC builds will be running in the same release+assert build
configuration.
This PR expands the nightly builds to run more of our supported build
configurations. This adds (almost) all combinations of the following
variables:
```
CXX = [clang++, g++]
BUILD_SHARED_LIBS = [ON, OFF]
LLVM_ENABLE_ASSERTION = [ON, OFF]
CMAKE_BUILD_TYPE = [Release, Debug]
```
The gcc+sharedlibs combinations have been disabled (see issue #708).
This leads to a total of 12 builds. Every build shares the same cached
version of LLVM and should only take a couple of minutes for each to
complete.
BUILD_SHARED_LIBS builds all libraries as shared libraries.
Historically, this has mostly been used as a developer productivity
flag, as it greatly speeds up linking. The real value in testing with
this flag enabled is that it reveals mistakes in CMake library
dependencies, such as missing dependencies and circular dependencies.
Additionally, there has been recent effort to increase the level of
support for shared libraries to enable MLIR C/Python bindings, and
supporting this flag down the line is probably a must.
Some changes can break the `circt-doc` target without anyone noticing.
This change adds it to CI pre-merge checks. Building the documentation
is very quick and should not affect build times in a significant way.
* Adding Windows build and test workflow
* ubuntu -> windows
* cmake paths
* Adding build parallelism
* Builds locally
* A large portion of the tests fail on Windows
* Remove release build
* Debug takes up waayyy too much space!
* Run in Release mode
* Add '-j 1' to disable parallelism
* Build LLVM separately
* Fixing build workflow
* Finally working!
* Update buildAndTestWindows.yml
Only cache object dirs
* Update buildAndTestWindows.yml
Fixing formatting issue
* Remove pre-build job
* Fix the lint steps to compare against the target branch
It was apparantly comparing against the fork point. Two different
meanings of the work base I think. As a result, it would pick up
differences in the target branch since the fork point! Users would have
to merge before the PR to avoid this.
* Documentation and breaking lines longer than 80 columns
(when possible)
* Missed a backslash
* Changing some of Amalee's code to test CODEOWNERS
* Workflow to automaticatly add reviewers
* Disabling ready_for_review
* Let's try herald
* Fixing workflow
* Totally messed up the format
Julian Oppermann