fix: prevent stale installed FTXUI headers from shadowing build sources - #1300
Merged
Conversation
Fixes #1299 ## Previous behaviour `ftxui_set_options()` exported the project `include/` directory as `SYSTEM INTERFACE` for `BUILD_INTERFACE`. This had an unintended side-effect when building FTXUI itself: - `screen` propagated `include/` into `dom`'s (and `component`'s) `INTERFACE_SYSTEM_INCLUDE_DIRECTORIES`. - CMake deduplicates: a path that appears in both `INCLUDE_DIRECTORIES` (from the `PRIVATE` rule) and `SYSTEM_INCLUDE_DIRECTORIES` (from the propagation above) is emitted **once, as `-isystem`**. - Clang/GCC search all `-I` paths before any `-isystem` path. Package managers such as MacPorts inject `-I/opt/local/include` via `CMAKE_CXX_FLAGS`. If an older FTXUI is already installed there, its headers are found first, causing the build to fail with errors like "no member named 'CellAt' in 'ftxui::Screen'". ## New behaviour When FTXUI is the **top-level CMake project** (i.e. being built from source, not consumed via `add_subdirectory`/`FetchContent`), the `BUILD_INTERFACE` include is exported as a plain `INTERFACE` (no `SYSTEM`). This prevents the SYSTEM propagation chain, so every FTXUI target keeps its own `include/` as a regular `-I` path that is searched before any system `-I` injected by the build environment. When FTXUI is **consumed** via `add_subdirectory` or `FetchContent`, the `SYSTEM INTERFACE` behaviour is retained, so downstream consumers continue to receive FTXUI headers as `-isystem` and do not see spurious warnings. The `INSTALL_INTERFACE` (used when FTXUI is found via `find_package`) is unchanged and remains `SYSTEM`. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…nd Screen Clang's -Wdeprecated-copy-with-dtor fires when a class declares a destructor but relies on the implicitly-generated copy constructor and copy assignment operator. Explicitly defaulting them silences the warning and makes the intent clear. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1299
Problem
When building FTXUI from source (e.g. a MacPorts package upgrade), an older installed version of FTXUI can shadow the headers being built, producing errors like:
Root cause — CMake include-directory deduplication
ftxui_set_options()exportedinclude/asSYSTEM INTERFACEforBUILD_INTERFACE. This created a propagation chain:screenaddsinclude/to itsINTERFACE_SYSTEM_INCLUDE_DIRECTORIES.domandcomponentlink againstscreen(PUBLIC), so they inheritinclude/in their ownSYSTEM_INCLUDE_DIRECTORIES.INCLUDE_DIRECTORIES(from thePRIVATErule) andSYSTEM_INCLUDE_DIRECTORIES(from propagation) is emitted once, as-isystem.-Ipaths before any-isystempath, regardless of command-line order.-I/opt/local/includeviaCMAKE_CXX_FLAGS. With an older FTXUI installed there, its headers are found first.Fix
When FTXUI is the top-level CMake project (
CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME), theBUILD_INTERFACEinclude is exported as a plainINTERFACE(droppingSYSTEM). This breaks the propagation chain so every FTXUI target keeps its owninclude/as a regular-Ipath, which is searched before any system path injected by the build environment.Behaviour matrix
-isystem— stale headers can win-I— project headers always win ✓add_subdirectory/FetchContentconsumer-isystem— no warnings-isystem— no warnings ✓find_packageconsumer (installed FTXUI)-isystem— no warnings-isystem— no warnings ✓The goal of suppressing warnings in consumer code is fully preserved.