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

Bump cc dependency #101

Merged
merged 1 commit into from
Oct 10, 2024
Merged

Bump cc dependency #101

merged 1 commit into from
Oct 10, 2024

Conversation

arttet
Copy link
Contributor

@arttet arttet commented Sep 26, 2024

Closes #100

@nagisa
Copy link
Member

nagisa commented Sep 26, 2024

Can't the Rust project bump the version in the lockfile? In principle there isn't anything wrong with (some?) older versions of cc in combination with (some?) older versions of MacOS and/or Rust toolchain.

@arttet
Copy link
Contributor Author

arttet commented Sep 26, 2024

Can't the Rust project bump the version in the lockfile?

We can do it, but it will be a workaround. If we want to fix the issue, we should bump this dependency.

In principle there isn't anything wrong with (some?) older versions of cc in combination with (some?) older versions of MacOS and/or Rust toolchain.

In general, older versions of cc cannot work with older versions of ARM64e macOS.
For example, we can build that target for 11 macOS.

@arttet
Copy link
Contributor Author

arttet commented Oct 7, 2024

Hi @nagisa,

I've reviewed this issue once more. Unfortunately, at the moment, I can only override the version for all dependencies and not specifically for this library, which is not what I need. Therefore, I've concluded that merging this PR is the only way to resolve the issue. I would appreciate it if you could review this PR again, as this issue is a blocker for me.

@nagisa nagisa merged commit ee7727f into rust-lang:master Oct 10, 2024
131 of 143 checks passed
@nagisa
Copy link
Member

nagisa commented Oct 10, 2024

Alright, I don't care super much either way.

I still don't follow your line of reasoning -- to me maintaining the lock file in a way that ensures project's functional requirements doesn't sound like a hack at all. I'm personally a strong believer that Cargo.toml dependency specifications should only reflect library API compatibility and nothing else (in most cases.) Besides, it looks like rust-lang/rust is already locking cc to 1.1.23 which is higher than the dependency specification PRd here, and there's only one copy of cc shared between all dependencies, so ultimately I don't really see what is being achieved here… Perhaps maybe only that you might now be able to build rustc with -Zminimal-versions on arm64e-macos? Is that the use-case?

@arttet arttet deleted the fix/cc branch October 10, 2024 12:54
@arttet
Copy link
Contributor Author

arttet commented Oct 10, 2024

Yes, it has already merged in Rust. I didn't see that MR. Anyway, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unknown architecture for macOS target
2 participants