Define RN_BUILDING for React Native's own CMake, SwiftPM, and Buck targets (#57861) - #57861
Open
coado wants to merge 1 commit into
Open
Define RN_BUILDING for React Native's own CMake, SwiftPM, and Buck targets (#57861)#57861coado wants to merge 1 commit into
coado wants to merge 1 commit into
Conversation
meta-cla
Bot
added
the
CLA Signed
facebook-github-tools
Bot
added
p: Software Mansion
|
@coado has exported this pull request. If you are a Meta employee, you can view the originating Diff in D115051088. |
coado
added a commit
to coado/react-native
that referenced
this pull request
Aug 11, 2026
…rgets (react#57861) Summary: Pull Request resolved: react#57861 React Native's public C++ headers are gaining guards from `react/cxxstableapi`, which turn a direct include of a fine-grained header into an error for consumers that opt into the strict API by defining `RN_STRICT_API`. React Native's own sources keep including those headers directly, so they are exempted via `RN_BUILDING`. Unlike CocoaPods, these three build systems each have a single chokepoint: - CMake: one `add_compile_definitions(RN_BUILDING)` in the ReactAndroid JNI project, a directory property inherited by every `add_react_common_subdir` below it. It is declared *after* the third-party NDK subdirectories so glog/boost/folly/fmt never see it, and this project never compiles app or third-party module code. - SwiftPM: one `.define` in the shared `Target.reactNativeTarget` factory that every React Native target is created through. `cxxSettings` are per-target and are not inherited by packages that depend on React. - Buck: a `_set_rn_building_flag` helper called from the four macros React Native's own targets use. It is `preprocessor_flags`, deliberately not `exported_preprocessor_flags`, so dependents are not exempted either. This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Differential Revision: D115051088
coado
force-pushed
the
export-D115051088
branch
from
August 11, 2026 10:41
a411d86 to
f3b72c7
Compare
meta-codesync
Bot
changed the title
coado
added a commit
to coado/react-native
that referenced
this pull request
Aug 12, 2026
…rgets (react#57861) Summary: Pull Request resolved: react#57861 React Native's public C++ headers are gaining guards from `react/cxxstableapi`, which turn a direct include of a fine-grained header into an error for consumers that opt into the strict API by defining `RN_STRICT_API`. React Native's own sources keep including those headers directly, so they are exempted via `RN_BUILDING`. Unlike CocoaPods, these three build systems each have a single chokepoint: - CMake: one `add_compile_definitions(RN_BUILDING)` in the ReactAndroid JNI project, a directory property inherited by every `add_react_common_subdir` below it. It is declared *after* the third-party NDK subdirectories so glog/boost/folly/fmt never see it, and this project never compiles app or third-party module code. - SwiftPM: one `.define` in the shared `Target.reactNativeTarget` factory that every React Native target is created through. `cxxSettings` are per-target and are not inherited by packages that depend on React. - Buck: a `_set_rn_building_flag` helper called from the four macros React Native's own targets use. It is `preprocessor_flags`, deliberately not `exported_preprocessor_flags`, so dependents are not exempted either. This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D115051088
coado
force-pushed
the
export-D115051088
branch
from
August 12, 2026 12:42
f3b72c7 to
c10aa8d
Compare
coado
added a commit
to coado/react-native
that referenced
this pull request
Aug 12, 2026
…rgets (react#57861) Summary: Pull Request resolved: react#57861 React Native's public C++ headers are gaining guards from `react/cxxstableapi`, which turn a direct include of a fine-grained header into an error for consumers that opt into the strict API by defining `RN_STRICT_API`. React Native's own sources keep including those headers directly, so they are exempted via `RN_BUILDING`. Unlike CocoaPods, these three build systems each have a single chokepoint: - CMake: one `add_compile_definitions(RN_BUILDING)` in the ReactAndroid JNI project, a directory property inherited by every `add_react_common_subdir` below it. It is declared *after* the third-party NDK subdirectories so glog/boost/folly/fmt never see it, and this project never compiles app or third-party module code. - SwiftPM: one `.define` in the shared `Target.reactNativeTarget` factory that every React Native target is created through. `cxxSettings` are per-target and are not inherited by packages that depend on React. - Buck: a `_set_rn_building_flag` helper called from the four macros React Native's own targets use. It is `preprocessor_flags`, deliberately not `exported_preprocessor_flags`, so dependents are not exempted either. This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D115051088
coado
force-pushed
the
export-D115051088
branch
from
August 12, 2026 12:48
c10aa8d to
d6ce5b5
Compare
coado
added a commit
to coado/react-native
that referenced
this pull request
Aug 12, 2026
…rgets (react#57861) Summary: Pull Request resolved: react#57861 React Native's public C++ headers are gaining guards from `react/cxxstableapi`, which turn a direct include of a fine-grained header into an error for consumers that opt into the strict API by defining `RN_STRICT_API`. React Native's own sources keep including those headers directly, so they are exempted via `RN_BUILDING`. Unlike CocoaPods, these three build systems each have a single chokepoint: - CMake: one `add_compile_definitions(RN_BUILDING)` in the ReactAndroid JNI project, a directory property inherited by every `add_react_common_subdir` below it. It is declared *after* the third-party NDK subdirectories so glog/boost/folly/fmt never see it, and this project never compiles app or third-party module code. - SwiftPM: one `.define` in the shared `Target.reactNativeTarget` factory that every React Native target is created through. `cxxSettings` are per-target and are not inherited by packages that depend on React. - Buck: a `_set_rn_building_flag` helper called from the four macros React Native's own targets use. It is `preprocessor_flags`, deliberately not `exported_preprocessor_flags`, so dependents are not exempted either. This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D115051088
coado
force-pushed
the
export-D115051088
branch
from
August 12, 2026 12:53
d6ce5b5 to
fbbb299
Compare
…rgets (react#57861) Summary: React Native's public C++ headers are gaining guards from `react/cxxstableapi`, which turn a direct include of a fine-grained header into an error for consumers that opt into the strict API by defining `RN_STRICT_API`. React Native's own sources keep including those headers directly, so they are exempted via `RN_BUILDING`. Unlike CocoaPods, these three build systems each have a single chokepoint: - CMake: one `add_compile_definitions(RN_BUILDING)` in the ReactAndroid JNI project, a directory property inherited by every `add_react_common_subdir` below it. It is declared *after* the third-party NDK subdirectories so glog/boost/folly/fmt never see it, and this project never compiles app or third-party module code. - SwiftPM: one `.define` in the shared `Target.reactNativeTarget` factory that every React Native target is created through. `cxxSettings` are per-target and are not inherited by packages that depend on React. - Buck: a `_set_rn_building_flag` helper called from the four macros React Native's own targets use. It is `preprocessor_flags`, deliberately not `exported_preprocessor_flags`, so dependents are not exempted either. This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D115051088
coado
force-pushed
the
export-D115051088
branch
from
August 13, 2026 09:28
fbbb299 to
423421a
Compare
coado
added a commit
to coado/react-native
that referenced
this pull request
Aug 13, 2026
…rgets (react#57861) Summary: Pull Request resolved: react#57861 React Native's public C++ headers are gaining guards from `react/cxxstableapi`, which turn a direct include of a fine-grained header into an error for consumers that opt into the strict API by defining `RN_STRICT_API`. React Native's own sources keep including those headers directly, so they are exempted via `RN_BUILDING`. Unlike CocoaPods, these three build systems each have a single chokepoint: - CMake: one `add_compile_definitions(RN_BUILDING)` in the ReactAndroid JNI project, a directory property inherited by every `add_react_common_subdir` below it. It is declared *after* the third-party NDK subdirectories so glog/boost/folly/fmt never see it, and this project never compiles app or third-party module code. - SwiftPM: one `.define` in the shared `Target.reactNativeTarget` factory that every React Native target is created through. `cxxSettings` are per-target and are not inherited by packages that depend on React. - Buck: a `_set_rn_building_flag` helper called from the four macros React Native's own targets use. It is `preprocessor_flags`, deliberately not `exported_preprocessor_flags`, so dependents are not exempted either. This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D115051088
coado
added a commit
to coado/react-native
that referenced
this pull request
Aug 13, 2026
…rgets (react#57861) Summary: React Native's public C++ headers are gaining guards from `react/cxxstableapi`, which turn a direct include of a fine-grained header into an error for consumers that opt into the strict API by defining `RN_STRICT_API`. React Native's own sources keep including those headers directly, so they are exempted via `RN_BUILDING`. Unlike CocoaPods, these three build systems each have a single chokepoint: - CMake: one `add_compile_definitions(RN_BUILDING)` in the ReactAndroid JNI project, a directory property inherited by every `add_react_common_subdir` below it. It is declared *after* the third-party NDK subdirectories so glog/boost/folly/fmt never see it, and this project never compiles app or third-party module code. - SwiftPM: one `.define` in the shared `Target.reactNativeTarget` factory that every React Native target is created through. `cxxSettings` are per-target and are not inherited by packages that depend on React. - Buck: a `_set_rn_building_flag` helper called from the four macros React Native's own targets use. It is `preprocessor_flags`, deliberately not `exported_preprocessor_flags`, so dependents are not exempted either. This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D115051088
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.
Summary:
React Native's public C++ headers are gaining guards from
react/cxxstableapi, whichturn a direct include of a fine-grained header into an error for consumers that opt into
the strict API by defining
RN_STRICT_API. React Native's own sources keep includingthose headers directly, so they are exempted via
RN_BUILDING.Unlike CocoaPods, these three build systems each have a single chokepoint:
add_compile_definitions(RN_BUILDING)in the ReactAndroid JNI project,a directory property inherited by every
add_react_common_subdirbelow it. It isdeclared after the third-party NDK subdirectories so glog/boost/folly/fmt never see
it, and this project never compiles app or third-party module code.
.definein the sharedTarget.reactNativeTargetfactory that everyReact Native target is created through.
cxxSettingsare per-target and are notinherited by packages that depend on React.
_set_rn_building_flaghelper called from the four macros React Native's owntargets use. It is
preprocessor_flags, deliberatelynot
exported_preprocessor_flags, so dependents are not exempted either.This change is inert on its own: nothing behaves differently unless a consumer defines
RN_STRICT_API.Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D115051088