feat: add link feature

[crowlKats]

The reason for this is that weak linking required for Deno to bring back webgpu support, and as we use the wgpu crate which depends on core-foundation, this feature flag needs to be added to core-foundation as well, as we are not going to be building with nightly or unstable rust features.

[jrmuizel]

Could you elaborate a bit more the context for this change?

[crowlKats]

As I have stated, this is necessary for Deno. This is because the WebGPU implementation was removed due to static linking causing massive startup time issues, and as the usage of said web API is not quite common yet, we decided to temporarily remove the implementation. Now we are looking into bringing WebGPU back into Deno, and to do that we need to weak link frameworks. We have started doing this already in the gfx-rs repos (gfx-rs/metal-rs#271, gfx-rs/wgpu#3853, gfx-rs/wgpu#3897), and the main & remaining frameworks used are coming from core-foundation.

[jrmuizel]

I still don't understand. Perhaps this is me not understanding what exactly#[link] does. How are the symbols resolved without it?

Also, macOS doesn't support statically linking against the system libraries so I don't understand what you mean when you say static linking caused a massive startup time issues.

[littledivy]

Hey @jrmuizel

With #[link], macOS will always load the framework at startup (dyld). We want to use -weak_framework to avoid this behaviour and save some startup time.

[madsmtm]

So ideally, I think we should work towards having the option in the language (#[link(name = "Foundation", kind = "weak_framework")]), such that the linking could still be specified by the library.

But since that's a bit farther away, I think this is a fine stopgap solution.

[jrmuizel]

Can you squash this into a single commit?

[bors-servo]

☔ The latest upstream changes (presumably b009c87) made this pull request unmergeable. Please resolve the merge conflicts.

[crowlKats]

apologies for the delay. @jrmuizel I have squashed all the commits.

[crowlKats]

@jrmuizel when can we expect new releases for the crates?

[jrmuizel]

Which crates do you all need releases for?

[crowlKats]

For now core-graphics-types would suffice, and we can wait for the other ones

[jrmuizel]

It looks like this will need core-foundation and core-foundation-sys too because of:

Caused by:
  failed to select a version for `core-foundation`.
      ... required by package `core-graphics-types v0.1.3 (/Users/jrmuizel/src/core-foundation-rs/target/package/core-graphics-types-0.1.3)`
  versions that meet the requirements `^0.9` are: 0.9.3, 0.9.2, 0.9.1, 0.9.0

  the package `core-graphics-types` depends on `core-foundation`, with features: `link` but `core-foundation` does not have these features.

[crowlKats]

I see; would it be possible to then publish those as well, or is there some blocker?

[jrmuizel]

The version specified for the dependencies will need to be updated.
e.g. https://github.com/servo/core-foundation-rs/blob/master/core-foundation/Cargo.toml#L15 will need to be bumped to 0.8.6 etc.
Can you make a PR bumping all the versions as needed?

[crowlKats]

@jrmuizel I looked through the repo and that spot seems the only one (as all other packages depend on non-fully qualified semvers). I am not really sure I understand how the release system works for this repo though, so I might be missing something.

[jrmuizel]

@crowlKats I made a new release of core-graphics-types

[crowlKats]

@jrmuizel thanks a lot!

[madsmtm]

EDIT: See #651