Skip to content

Conversation

@marcfir
Copy link
Contributor

@marcfir marcfir commented Sep 22, 2025

Any reasosn for CMAKE_CURRENT_BINARY_DIR?

@gemini-code-assist
Copy link

Summary of Changes

Hello @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 config.h is placed in the source tree's include directory rather than the build directory, which likely corrects the file's intended location and prevents potential build or inclusion problems.

Highlights

  • CMake Configuration Path: The output path for the config.h file generated by the configure_file command in CMakeLists.txt has been updated. It now directs the output to ${CMAKE_CURRENT_SOURCE_DIR}/include/libethercat/config.h instead of ${CMAKE_CURRENT_BINARY_DIR}/include/libethercat/config.h.
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

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.

Copy link

@gemini-code-assist gemini-code-assist bot left a 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)

Choose a reason for hiding this comment

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

high

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)

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.

1 participant