Skip to content
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

[SR-2342] Support standalone builds of a full CoreFoundation.framework #4341

Open
swift-ci opened this issue Aug 15, 2016 · 9 comments
Open

[SR-2342] Support standalone builds of a full CoreFoundation.framework #4341

swift-ci opened this issue Aug 15, 2016 · 9 comments

Comments

@swift-ci
Copy link
Contributor

@swift-ci swift-ci commented Aug 15, 2016

Previous ID SR-2342
Radar None
Original Reporter copumpkin (JIRA User)
Type New Feature
Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels New Feature, BuildScript
Assignee None
Priority Medium

md5: 64fb215d00bd420034547cca8a6c30c9

Issue Description:

I was very pleased to see 87d1a97, which allowed us to build CoreFoundation independently of Foundation, but that build still only builds a static library. A naive switch of StaticLibrary to Framework leads to weird ninja dependency errors (I can't find an example using the Framework product), and switching it for DynamicLibrary produces a ton of linker errors (mostly because it doesn't link ICU or libxml2, and doesn't inject all the __UNICODE symbols into the result object).

Highlighting @phausler as the author of the commit in question.

Edit: the above is all currently fixed, and DynamicLibrary is now the default. This issue is about trying to switch DynamicLibrary to Framework.

Motivation: the Nix package manager aims to be a (nearly) fully deterministic build system (with a strong preference for builds from source), and as part of that we build a full Mac toolchain from scratch (no Xcode or command-line tools). To do that, we use a wide range of Apple's open-source releases on opensource.apple.com. Unfortunately, Apple only releases a reduced version of CoreFoundation on there, and although it works for most of our use cases, the slight discrepancies between CF (-lite) and the proper CoreFoundation cause us some subtle issues. The CoreFoundation included in the swift Foundation project appears to be more complete and better suited to our use case.

@phausler
Copy link
Member

@phausler phausler commented Aug 15, 2016

The `Framework` target type is not really supported (it was partially abandoned since Linux targets don't support framework linker and compiler flags).

`DynamicLibrary` would be the correct target type. However we would need to add a number of linkages (but imho the swift-corelibs-foundation should be still linking CF statically into Foundation)

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Aug 15, 2016

Comment by Dan Peebles (JIRA)

Ah, that makes sense. I agree that this Foundation might still want to use CF statically, but do you envision a DynamicLIbrary build of it possibly living in the same repository? If I contributed code to build a .framework (since there are still potential gotchas about which headers to include and which should stay private), would that get accepted to the repository?

I'm basically looking for expertise in bridging the gap between what's currently in this repository (which looks ideal in terms of pure C code) and what we currently have in CF-lite. I can maintain build scripts on my side to glue together all the headers and framework folder paths, but that kind of logic seems like it belongs upstream somewhere.

Ultimately, if this were my project, I'd probably split CF out into swift-corelibs-corefoundation, give it the ability to build dynamically, statically, and a standard framework, and then have swift-corelibs-foundation statically depend on that. Obviously that's not my call to make, but it would obviously please me and your loyal (wannabe) Nix users 🙂

@phausler
Copy link
Member

@phausler phausler commented Aug 15, 2016

Well the one part of building a framework target is that if a user builds it for Mac OS X, that CF will NOT work as a replacement to the system one. So I think if we kept it as a dylib/so it would keep in line with the concept of CFLite and perhaps be slightly easier to keep up to date.

I don't think at the current moment we will be splitting them up since CF is an "implementation detail" of swift-corelibs-foundation. But I think it might be reasonable to alter the config file to support both a static and dynamic product.

@phausler
Copy link
Member

@phausler phausler commented Aug 15, 2016

It is also worth noting that I have tinkered around with alternate builder-build systems for swift-corelibs-foundation (cmake etc). So I don't think we are married to the idea of the python monstrosity and that could be simplified down to something else that we could pass the buck and not have to maintain.

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Aug 15, 2016

Comment by Dan Peebles (JIRA)

Yeah, definitely wasn't intending to replace the system framework. A big part of Nix is that we don't touch system files.

Anyway, perhaps I should try submitting a PR adding a DynamicLibrary build product? I'm not sure how to cleanly switch between the two in the python+ninja build system you have in place today. Any hints?

@phausler
Copy link
Member

@phausler phausler commented Aug 15, 2016

I think if the configure script had some sort of parameter to determine which build path is taken that would help, perhaps take a line out of the page of other config scripts with parameters passed to the configure script of `-static` or `-dynamic` or both which then triggers an if statement in the build.py for CF that flips adding build products.

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Oct 13, 2016

Comment by Dan Peebles (JIRA)

Just to elaborate on the sort of thing I'm looking for, we're currently in an awkward spot between http://opensource.apple.com/source/CF/CF-1153.18 and the CoreFoundation in the swift open releases. The former has a nice Makefile that builds a full .framework with all the headers and other files in the places they belong, but is unfortunately redacted and doesn't provide the full functionality of the latter. The latter has more functionality but has no build process to produce the .framework.

I hope to be looking at the DynamicLibrary product soon, but the .framework stuff is still important to me.

To put it differently, if you don't want to add build code to produce the .framework, can the CoreFoundation subdirectory include a quick readme explaining the core remaining differences between it and the system CF?

Thanks!

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Sep 14, 2018

Comment by Dan Peebles (JIRA)

@parkera @millenomi

This was one of my original tickets against the repo a bajillion years ago, and I mentioned this request again more recently on the forum.

I'm now wondering: I do have CoreFoundation/build.py sort of kind of working with the Framework build product in a local branch. I haven't submitted it yet because the current version breaks the root build.py. I originally mentioned adding some branching to CoreFoundation/build.py to support building both the DynamicLibrary and the Framework but who actually uses CoreFoundation/build.py? Does anyone actually want the DynamicLibrary product or is that just an artifact of the Foundation build? If I could keep the Foundation build.py healthy while also making CoreFoundation/build.py produce the framework by default, would that be a welcome change or would I be breaking someone else who depends on CoreFoundation/build.py to produce a .dylib?

Relatedly, there's a fair amount of duplication between the two build.py files, which I've been tempted to factor out in an effort to make it harder for them to get out of sync.

Does any/all of that sound appealing? I'm mostly somewhat constrained by not knowing who uses what and how (like are these build.py files even here to stay? I keep seeing stuff about CMake) so I don't want to pour a ton of effort into something that's going to disappear next week 🙂 if it sticks around for a few more months, it'd probably be worth it to me though to streamline this.

@parkera
Copy link
Member

@parkera parkera commented Sep 14, 2018

I don't know about build.py disappearing next week, but I think it would be best for us to consider using CMake in the future. We avoided it early on because of the additional complexity, but the fact is that most of the rest of the Swift stack is using it. It may be better to remain consistent. Unfortunately I'm not a domain expert on CMake so I'm not 100% sure what the impact may be on switching to it from our custom build stuff.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants