-
Notifications
You must be signed in to change notification settings - Fork 11
fix: cmake configure_file path #41
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
base: master
Are you sure you want to change the base?
Conversation
Summary of ChangesHello @marcfir, I'm Gemini Code Assist1! 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 resolves a configuration issue within the CMake build system by adjusting the destination path for a generated header file. The change ensures that Highlights
Using Gemini Code AssistThe 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
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 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
|
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.
Code Review
This pull request changes the output path for the generated config.h file from the CMake binary directory to the source directory. While this might seem to align with how settings.h is handled on the next line, it introduces a deviation from CMake best practices. Generating files into the source directory can cause issues with out-of-source builds and version control. My review comment explains why the original approach of using the binary directory is correct and suggests reverting the change.
| endif() | ||
|
|
||
| configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cmake/cmake_config.h.in ${CMAKE_CURRENT_BINARY_DIR}/include/libethercat/config.h) | ||
| configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cmake/cmake_config.h.in ${CMAKE_CURRENT_SOURCE_DIR}/include/libethercat/config.h) |
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.
This change directs the generated config.h file into the source directory (CMAKE_CURRENT_SOURCE_DIR). This is generally considered bad practice in CMake as it pollutes the source tree with build artifacts. The original use of CMAKE_CURRENT_BINARY_DIR was correct because it places generated files in the build directory.
This is important for a few reasons:
- Out-of-source builds: It allows for clean separation of source code and build artifacts. You can have multiple build directories (e.g., for debug, release, different toolchains) from a single source tree without them interfering with each other.
- Version Control: It prevents generated files from being accidentally committed to your repository.
The original code followed these best practices. If the goal was to ensure config.h is installed, a better approach would be to add a specific install() rule for the file after it's generated in the binary directory, rather than changing its generation path.
I recommend reverting this change to adhere to standard CMake practices. The same principle also applies to settings.h on the next line, which should also ideally be generated into CMAKE_CURRENT_BINARY_DIR.
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cmake/cmake_config.h.in ${CMAKE_CURRENT_BINARY_DIR}/include/libethercat/config.h)
Any reasosn for
CMAKE_CURRENT_BINARY_DIR?