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)

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 🙂

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.

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.

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?

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.

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!

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.

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.