build: add VS Code DevContainer support for seamless onboarding

[Divinesoumyadip]

Currently, developers using Docker must manually run container build commands, configure volume mounts, and manually attach their IDEs to the container environment. This creates friction and a steep learning curve for first-time contributors.

By adding native DevContainer support, users can now simply open the cloned repository in VS Code and click "Reopen in Container".

This configuration automatically:

1. Builds against the dev target in our existing Dockerfile (leveraging the optimized base image).
2. Sets up the correct workspace mounting automatically.
3. Pre-installs essential VS Code extensions for OpenROAD development (cpptools, cmake-tools, etc.).
4. Drops the user into a ready-to-use root bash terminal.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[gemini-code-assist]

Code Review

This pull request introduces DevContainer support, which is a valuable addition for streamlining the developer onboarding process. My review focuses on refining the configuration for robustness and maintainability. I've suggested simplifying the VS Code extensions list by removing redundant entries and correcting the postCreateCommand to prevent potential container lifecycle issues. These changes will help ensure a smooth experience for developers using the new DevContainer environment.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[Divinesoumyadip]

Hi @vvbandeira Please chcek it out .Thanks in advance .

[vvbandeira]

@Divinesoumyadip
First of all, thanks for the contribution!

I have mixed feelings about this PR.

If the goal is simply to provide an additional way to use/develop OR, I'm okay with merging it.
If the goal is to make this the foundation for documentation, I lean against merging it, though I'm open to further discussion.

We previously tried devcontainers for ORFS, but we abandoned that approach.
One major issue was GUI support: it required a specialized Docker image, which became difficult to maintain since almost no one was using devcontainers.

I also don't think this is the best onboarding path. It assumes users will work in a devcontainer (most likely via VS Code). For users who don't already use VS Code or another IDE with devcontainer support, requiring them to install a new IDE works against ease of use.

[Divinesoumyadip]

@Divinesoumyadip First of all, thanks for the contribution!

I have mixed feelings about this PR.

If the goal is simply to provide an additional way to use/develop OR, I'm okay with merging it. If the goal is to make this the foundation for documentation, I lean against merging it, though I'm open to further discussion.

We previously tried devcontainers for ORFS, but we abandoned that approach. One major issue was GUI support: it required a specialized Docker image, which became difficult to maintain since almost no one was using devcontainers.

I also don't think this is the best onboarding path. It assumes users will work in a devcontainer (most likely via VS Code). For users who don't already use VS Code or another IDE with devcontainer support, requiring them to install a new IDE works against ease of use.

@vvbandeira Thanks for the detailed review!
You're right that devcontainers aren't for everyone. This PR is purely additive , developers not using VS Code won't even notice the .devcontainer folder exists. It doesn't replace the existing Build.sh or DependencyInstaller.sh workflow in any way.
The GUI concern is valid, but this config targets the development/build workflow only, not GUI usage. For VS Code users who want a zero-friction setup, this gives them that option.
Happy to add a one-liner in the README clarifying it's optional. Would that be sufficient for your approval?

[vvbandeira]

This PR is purely additive , developers not using VS Code won't even notice the .devcontainer folder exists.

Then the PR is fine.

Happy to add a one-liner in the README clarifying it's optional.

If VSCode let's their user know somehow that the repo has a .devcontainer, then no further action is required.
If there's no indication, we should add a note somewhere to let people know this exist, the limitations and expected usage -- not sure the README is the best place, maybe on the same doc where we talk about docker and other install methods.

[Divinesoumyadip]

This PR is purely additive , developers not using VS Code won't even notice the .devcontainer folder exists.

Then the PR is fine.

Happy to add a one-liner in the README clarifying it's optional.

If VSCode let's their user know somehow that the repo has a .devcontainer, then no further action is required. If there's no indication, we should add a note somewhere to let people know this exist, the limitations and expected usage -- not sure the README is the best place, maybe on the same doc where we talk about docker and other install methods.

@vvbandeira Thanks! I'll add a brief note about the DevContainer in docs/user/BuildWithDocker.md mentioning it exists, its limitations (no GUI support), and expected usage. Will push the update shortly.

[Divinesoumyadip]

@vvbandeira I've added a note about the DevContainer in docs/user/BuildWithDocker.md mentioning its limitations (no GUI support) and that it's purely optional. Please review when you get a chance!

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[vvbandeira]

Duplicated sections, this filename does not match the contents -- also we already have a section on Docker.
Rename the file, add a reference in the correct place.
Please review your own PR carefully to make sure you have committed and pushed the correct set.

[Divinesoumyadip]

Duplicated sections, this filename does not match the contents -- also we already have a section on Docker. Rename the file, add a reference in the correct place. Please review your own PR carefully to make sure you have committed and pushed the correct set.

@vvbandeira Done now check.Thanks

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"