fix: optimize makefile for devcontainers and guard gds flow

[anlit75]

Summary

This PR improves the developer experience for VS Code DevContainer users by implementing a "Hybrid Execution" strategy in the Makefile. It also adds safeguards to the GDSII flow to prevent accidental execution in unsupported environments.

Key Changes

🛠️ Makefile & DevContainer DX

• Hybrid Execution: The Makefile now detects if it is running inside the DevContainer (by checking for /opt/c4o-core/...).
  • Inside Container: Directly executes the Python entrypoint script (Faster, avoids Docker-in-Docker errors).
  • On Host: Continues to use docker run to invoke the c4o-core image.
• GDS Guardrail: Added a check to make gds. If run inside a DevContainer, it immediately exits with a helpful error message instructing the user to switch to the Host terminal.
• Lazy PDK Installation: Moved make pdk dependency inside the gds target. The huge PDK download now triggers only after the environment check passes.

[gemini-code-assist]

Summary of Changes

Hello @anlit75, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the developer experience for users working with VS Code DevContainers by introducing a "Hybrid Execution" strategy in the Makefile. It optimizes command execution by detecting the environment and directly running Python scripts when inside a container, avoiding Docker-in-Docker issues. Additionally, it improves the robustness of the GDSII flow by implementing a guardrail that prevents accidental execution in unsupported DevContainer environments and defers PDK installation until it's genuinely needed.

Highlights

• DevContainer Hybrid Execution: The Makefile now intelligently detects if it's running inside a DevContainer. If so, it directly executes Python entrypoint scripts, bypassing Docker-in-Docker. Otherwise, it defaults to 'docker run' on the host.
• GDS Flow Guardrail: A new check in the 'make gds' target prevents its execution within a DevContainer, providing an error message and instructing users to run it from the host terminal.
• Lazy PDK Installation: The 'make pdk' dependency has been moved inside the 'gds' target, ensuring the large PDK download only occurs after environment checks pass, optimizing resource usage.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• .gitignore
  • Added 'pdks' directory to the ignore list.
• Makefile
  • Introduced logic to detect if the script is running inside a DevContainer by checking for a specific entrypoint script.
  • Defined 'C4O_CMD' variable to conditionally execute commands either directly via Python (in-container) or via 'docker run' (on-host).
  • Updated 'lint', 'sim', 'synth', and 'pdk' targets to utilize the new 'C4O_CMD' variable for command execution.
  • Implemented a guard clause in the 'gds' target to prevent its execution within a DevContainer, providing an informative error message.
  • Modified the 'gds' target to lazily install PDKs by moving the 'pdk' dependency inside the target itself.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/verify.yml

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively improves the developer experience for dev container users by introducing a hybrid execution model in the Makefile. The logic to differentiate between the host and container environments is a great addition. The safeguard for the gds flow to prevent execution inside the container is also a thoughtful touch that will prevent user errors. I have one suggestion to make the container detection logic even more robust by using a standard dev container environment variable instead of a file path check. Overall, this is a solid improvement.

[gemini-code-assist]

The current method for detecting if the Makefile is running inside a dev container relies on checking for a specific file path (/opt/c4o-core/scripts/entrypoint.py). This creates a coupling between the Makefile and the container's internal file structure. A more robust and idiomatic approach for VS Code dev containers is to check for the REMOTE_CONTAINERS environment variable, which is automatically set to true in this context. This decouples the detection logic from the image's file layout, making it more resilient to future changes.

# Check if we are running inside a VS Code Dev Container
ENTRYPOINT_SCRIPT := /opt/c4o-core/scripts/entrypoint.py

ifeq ($(REMOTE_CONTAINERS),true)
	# Case A: We are inside the DevContainer
	IS_IN_CONTAINER := yes
	C4O_CMD := python3 $(ENTRYPOINT_SCRIPT)
else
	# Case B: We are on the Host Machine
	IS_IN_CONTAINER := no
	C4O_CMD := $(DOCKER_RUN) $(C4O_IMAGE)
endif