Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace outdated unified build example with a devcontainer which demonstrates a unified build #6305

Closed
wants to merge 16 commits into from

Conversation

GeorgeLyon
Copy link
Contributor

The old example wasn't used as far as I can tell. The added benefit of this approach is that we can validate the configuration in CI as well.

This can also be used "out-of-the-box" (provided you have VSCode devcontainers set up) as opposed to having to copy and modify the example.`

Copy link
Contributor

@dtzSiFive dtzSiFive left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow. Helping VSCode users is good but don't know about this. Will try to find time to revisit later. Thanks for submitting/sharing.


# Calls CMake, loading arguments from devcontainer settings to maintain a single source of truth.

PROJECT_NAME=circel
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
PROJECT_NAME=circel
PROJECT_NAME=circt

Or, what's circel?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, thought I had gotten all the copypasta... This whole infra is something I was using for SIL, and am currently using a revised version of for Chisel bindings (circel).


# Different versions of clang and Java can be selected by specifying the following build arguments, but are not guaranteed to work.
ARG CLANG_VERSION=17
ARG JAVA_VERSION=java11
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-Java?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copy pasta, will remove

"-DLLVM_USE_SANITIZER=",

// LLVM (performance)
"-DLLVM_USE_LINKER=lld-17",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is lld-17 good here, or should this be set/substituted in? Similarly, clangd-17 below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh generally looks like this hardcodes things that are variables elsewhere (e.g., build paths). Should this be generated instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the Dockerfile essentially defines the state of the VM. In this VM, all the LLVM stuff is suffixed 17 (because that is how the package is set up). A different VM would have different hardcodings. I wouldn't generate this, as it is nice to not need to run a "generator" before being able to use the project. The least I would do is validate this is accurate in CI, which this PR kind of does.

"--compile-commands-dir=${workspaceFolder}/build/circt",
"--header-insertion=never",
"--clang-tidy",
"--clang-tidy-checks=*",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious, why all checks? (and not using the project's .clang-tidy?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The clang-tidy stuff is relatively new, I'll remove this line

"runArgs": [
"--cap-add=SYS_PTRACE",
"--security-opt",
"seccomp=unconfined"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this about?

jq \
#
# ShellCheck is useful for validating bash scripts
shellcheck \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍


1. Install Docker, a tool for managing containerized VMs: https://www.docker.com
- If you have Docker installed, make sure it is updated to the most recent version (there is a "Check for Updates" option in the application UI).
- If installing Docker on macOS for the first time, I recommend selecting the "Advanced" installation option, specifying a "User" installation and disabling the two options below. This makes it so your Docker installation does not require root privileges for anything, making updates more seamless. This will require you telling VSCode where the `docker` executable ended up by chaging the "dev.containers.dockerPath" setting `"/Users/<your-user-name>/.docker/bin/docker”`. You should make sure this executable exists by executing `"/Users/<your-user-name>/.docker/bin/docker --version”`, if you are not on macOS the `docker` executable might be at a different path.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- If installing Docker on macOS for the first time, I recommend selecting the "Advanced" installation option, specifying a "User" installation and disabling the two options below. This makes it so your Docker installation does not require root privileges for anything, making updates more seamless. This will require you telling VSCode where the `docker` executable ended up by chaging the "dev.containers.dockerPath" setting `"/Users/<your-user-name>/.docker/bin/docker”`. You should make sure this executable exists by executing `"/Users/<your-user-name>/.docker/bin/docker --version”`, if you are not on macOS the `docker` executable might be at a different path.
- If installing Docker on macOS for the first time, I recommend selecting the "Advanced" installation option, specifying a "User" installation and disabling the two options below. This makes it so your Docker installation does not require root privileges for anything, making updates more seamless. This will require you telling VSCode where the `docker` executable ended up by chamging the "dev.containers.dockerPath" setting `"/Users/<your-user-name>/.docker/bin/docker”`. You should make sure this executable exists by executing `"/Users/<your-user-name>/.docker/bin/docker --version”`, if you are not on macOS the `docker` executable might be at a different path.

@@ -0,0 +1,40 @@
## Using VSCode devcontainers

VSCode supports creating development environments inside of a docker container. With some light configuration, we can get a consistent development environment that is robust to changes in your local environment and also doesn't require you to install and manage dependencies on your machine.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cries in Nix

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried to use nix every so often. The fact that it nix hyper-intrusive on Mac (haven't checked if this has changed recently) is non-starter for me. Docker can be installed with no privileges and uses Apple's VM frameworks so is quite performant on M-series chips. I find I don't actually need Nix's level of hermeticity, and Docker's usability wins for me here.

fi
fi

set -e
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I missed something, this is set at top already and not unset?

@@ -0,0 +1,94 @@
#!/usr/bin/env bash

set -e
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider, set -euo pipefail -- or however you want to do it-- make error using variables not set (looks like nice and careful about this so might as well) and make a | b | c not only fail if c does.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, I keep meaning to do this but only set -e is stored in my brain.

@GeorgeLyon
Copy link
Contributor Author

@teqdruid Could be interesting to unify this with the CI image (i.e. CI can just be an additional devcontainer configuration).

Copy link
Contributor

@mikeurbach mikeurbach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for providing an updated setup, I think it is good to have things like this checked in. However, I'm also concerned about the impact on CI from this change, both in terms of cache and runtime. It looked like the validate devcontainer step took a significant amount of CI time on this PR. IMHO it's good to have local setup things like checked in, but I don't know if it's worth the trade off to have them checked by CI.

@@ -73,6 +72,10 @@ jobs:
run: |
# Run clang-format
git clang-format $DIFF_COMMIT

# clang-format unnecessarily formats some JSON in this directory, and disagrees with VSCode's formatting rules
git checkout HEAD -- .devcontainer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to configure clang-format to ignore certain files?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I found. Pretty weird that it formats JSON too...

./.devcontainer/cmake-helper configure

# We run the build, once to check the targets and once to log the errors without any progress logs cluttering the output (since it is a trivial incremental build). Please take care to make sure the following two steps stay in sync.
- name: Check targets
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to add a full run of the tests? At least on this PR, it seems to be a long pole on the pre merge CI.

@GeorgeLyon
Copy link
Contributor Author

@mikeurbach I tweaked some things and now the devcontainer validates in just over 5 minutes on a cache hit, which seems pretty reasonable. Cache size isn't that bad either, coming in at under 400MB.

@GeorgeLyon GeorgeLyon force-pushed the dev/george/devcontainer branch from d4aa19b to 3317678 Compare October 27, 2023 18:25
@GeorgeLyon GeorgeLyon closed this Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants