-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
Project: streamline BuildProfile handling #1154
Conversation
WalkthroughThe changes update the initialization flows in both the BuildConfig and Project classes. In BuildConfig, the instantiation of the Project has been revised to include a build profile parameter and streamline variable setup. In the Project class, initialization logic has been refactored with new overloaded init methods, an updated constructor that incorporates the build profile, and the addition of a new root path member. A minor cleanup also removes a redundant blank line in the formatting command. Changes
Sequence Diagram(s)sequenceDiagram
participant BC as BuildConfig
participant P as Project
participant FS as Filesystem
participant Repo as Repository
BC->>FS: Get current_path()
BC->>P: Project::init(buildProfile, current_path)
alt Initialize via Manifest
P->>P: Create Manifest from current_path
end
P->>P: Construct Project (buildProfile, Manifest, Compiler)
P->>P: Call includeIfExist("src") & includeIfExist("include")
P->>Repo: repo.open(rootPath.string())
P-->>BC: Return initialized Project
Possibly related PRs
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/Builder/Project.cc (1)
176-181
: Optional logging for missing include directories.
includeIfExist
silently ignores directories that do not exist. Adding a debug or trace log could help diagnose misconfigurations when a directory is overlooked.src/Builder/Project.hpp (1)
15-17
: Consider using pass-by-reference or rvalue reference.The constructor parameters accept a
Manifest
andCompiler
by value. If these objects are large, using rvalue references or const references (with a move in the implementation) can optimize performance while preserving clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/BuildConfig.cc
(1 hunks)src/Builder/Project.cc
(3 hunks)src/Builder/Project.hpp
(1 hunks)src/Cmd/Fmt.cc
(0 hunks)
💤 Files with no reviewable changes (1)
- src/Cmd/Fmt.cc
🧰 Additional context used
🪛 Cppcheck (2.10-2)
src/Builder/Project.cc
[performance] 88-88: Function parameter 'cFlags' should be passed by const reference.
(passedByValue)
[performance] 88-88: Function parameter 'ldFlags' should be passed by const reference.
(passedByValue)
⏰ Context from checks skipped due to timeout of 90000ms (12)
- GitHub Check: analyze (c-cpp)
- GitHub Check: build & test (GCC 12)
- GitHub Check: build & test (Clang 19)
- GitHub Check: build & test (Clang 17)
- GitHub Check: build & test (GCC 13)
- GitHub Check: build & test (Apple Clang - macOS 14)
- GitHub Check: build & test (Apple Clang - macOS 15)
- GitHub Check: build & test (GCC 14)
- GitHub Check: build & test (Apple Clang - macOS 13)
- GitHub Check: build & test (Clang 18)
- GitHub Check: build & test (Clang 16)
- GitHub Check: create
🔇 Additional comments (9)
src/BuildConfig.cc (1)
72-74
:❓ Verification inconclusive
Confirm the current path usage.
By calling
Project::init(buildProfile, fs::current_path())
, the project's root path is set to the current working directory, which might not match the intended source root if the command is run from a subdirectory. Please verify that this is desired behavior.
🏁 Script executed:
#!/bin/bash # Description: Locate all call sites of Project::init to ensure consistency with rootDir usage. rg -A 3 -B 3 'Project::init'Length of output: 1191
Action Required: Confirm Project Root Initialization Behavior
The call to
Project::init(buildProfile, fs::current_path())
insrc/BuildConfig.cc
sets the project's root path to the current working directory. Our search confirms that this is the sole call site and that the implementation insrc/Builder/Project.cc
relies on the provided path to locate the manifest file. Please verify that usingfs::current_path()
is indeed the intended behavior even when executing the command from a subdirectory. If the current working directory might not correctly represent the desired source root, consider adjusting the initialization logic or adding documentation to clarify the behavior.src/Builder/Project.cc (5)
80-92
: Constructor implementation looks good.The constructor properly initializes paths, compiler options, and includes relevant directories. This approach helps organize configuration logic and simplifies subsequent method calls.
🧰 Tools
🪛 Cppcheck (2.10-2)
[performance] 88-88: Function parameter 'cFlags' should be passed by const reference.
(passedByValue)
[performance] 88-88: Function parameter 'ldFlags' should be passed by const reference.
(passedByValue)
122-122
: Check error handling for repository initialization.Switching from opening
"."
to usingrootPath.string()
is a logical change. However, ensure that errors are handled gracefully ifrootPath
is not a valid Git repository or is inaccessible.
174-175
: No review needed for closing braces.
183-188
: Manifest parsing approach is acceptable.Reading and parsing the manifest file from the specified directory is expected. Validation of the manifest's existence is already handled via
Try(...)
, so no additional changes are required here.
189-192
: Initialization method aligns with new constructor.This overload clearly supports initializing projects directly from an in-memory
Manifest
object, which is consistent with the updated constructor.src/Builder/Project.hpp (3)
22-22
: Public root path usage is clear.Exposing
rootPath
as a read-only member ensures other modules can reference the project’s base directory without risking accidental modification.
26-27
: Addition of static init method.
init(const BuildProfile&, const fs::path&)
centralizes the creation logic and fosters consistent configuration across different callers.
29-30
: Overload for manifest-based initialization is concise.Allowing direct initialization with an already loaded
Manifest
is useful for scenarios where the manifest is processed before project creation.
Summary by CodeRabbit
New Features
Refactor
Style