[CF] Preliminary support for standalone builds. #2646
Conversation
3405691582
force-pushed
the
CMakeStandalone
branch
2 times, most recently
from
bdd5169 to
d097302
Compare
CoreFoundation gets built as a framework. TargetConditionals.h is a public header in this framework, so in order for the compiler to find the header, it has to be referenced through the framework, that is, <CoreFoundation/TargetConditionals.h>. In CFBase.h, if we are building standalone (c.f. swiftlang#2646), we are not DEPLOYMENT_RUNTIME_SWIFT and so we try and look for TargetConditionals.h with <TargetConditionals.h>. Presumably this is fine on macOS, since perhaps this is included elsewhere on that system, but on other platforms this won't be found and we get an error. But it's actually unnecessary to reference any other TargetConditionals.h that may be defined elsewhere, because TargetConditionals.h is part of the CoreFoundation framework. It is then similarly unnecessary to test for the include, or to fall back on any other TargetConditionals.h, so just refer to it in the framework unconditionally. If there are any problems, we get a straightforward compiler error.
CoreFoundation/CMakeLists.txt
Outdated
| @@ -373,7 +377,8 @@ add_framework(CoreFoundation | |||
| URL.subproj/CFURLAccess.c | |||
| URL.subproj/CFURL.c | |||
| URL.subproj/CFURLComponents.c | |||
| URL.subproj/CFURLComponents_URIParser.c) | |||
| URL.subproj/CFURLComponents_URIParser.c | |||
| ${CF_SWIFT_SOURCES}) | |||
There was a problem hiding this comment.
Please use target_sources for adding the additional source file.
CoreFoundation/CMakeLists.txt
Outdated
| install(TARGETS | ||
| CoreFoundation | ||
| CFURLSessionInterface | ||
| CFXMLInterface | ||
| ${CF_SWIFT_TARGETS} |
There was a problem hiding this comment.
I think it may be nicer to just use a property that you append to, rather than doing the variable expansion here.
There was a problem hiding this comment.
I may be misunderstanding something. Do you mean use set_property() for something? If so, I'm not quite sure how you mean to apply it here.
For the moment, I've pulled out CFXMLInterface into a separate install(), which avoids the variable expansion. Maybe this is better too?
There was a problem hiding this comment.
Im basically trying to avoid the whole variable soup that CMake <3.0 used to suffer from. Adding a second install(TARGETS) in an if is another approach.
This commit makes some preliminary fixes for standalone builds using
cmake. The standalone and Swift builds are similar, except for:
* the CoreFoundation umbrella header,
* ForSwiftFoundationOnly.h,
* CFXMLParser.c and CFXMLNode.c, since these have CFTypeIDs that are
present in CFRuntime_Internal.h behind DEPLOYMENT_RUNTIME_SWIFT, and
* CFXMLInterface, since it refers to struct _NSCFXMLBridge, and this is
defined in ForSwiftFoundationOnly.h.
Not present is a mechanism to refer to Block.h or dependent libraries.
3405691582
force-pushed
the
CMakeStandalone
branch
from
d097302 to
4ee6004
Compare
|
I've also added some indents appropriately where there were missing before. |
|
@swift-ci test linux |
|
@swift-ci please test |
|
The Swift project moved the default branch to More detail about the branch update - https://forums.swift.org/t/updating-branch-names/40412 |
This commit makes some preliminary fixes for standalone builds using
cmake. The standalone and Swift builds are similar, except for:
the CoreFoundation umbrella header,
ForSwiftFoundationOnly.h,
CFXMLParser.c and CFXMLNode.c, since these have CFTypeIDs that are
present in CFRuntime_Internal.h behind DEPLOYMENT_RUNTIME_SWIFT, and
CFXMLInterface, since it refers to struct _NSCFXMLBridge, and this is
defined in ForSwiftFoundationOnly.h.
Not present is a mechanism to refer to Block.h or dependent libraries.
Problems including TargetConditionals.h is dealt with in #2653.
(I'm not well-versed in cmake-speak, so if there's more idiomatic or stylistic ways of doing this, please let me know.)