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

Add support for cross cc compilers #240

Merged
merged 4 commits into from
Aug 10, 2023
Merged

Add support for cross cc compilers #240

merged 4 commits into from
Aug 10, 2023

Conversation

layus
Copy link
Collaborator

@layus layus commented Jun 28, 2022

In the current state, cc.nix is not compatible with crossPkgs and cross compilers.

This PR makes some progress by using buildPackages instead of pkgs where needed (everywhere, except stdenv.cc).

To get a cross toolchain one still needs to provide a nixpkgs with an hard-coded cross config. Alternatively, an expression that provides a cross compiler should also work without modifying the nixpkgs argument to nixpkgs_cc_configure.

But providing such an expression is difficult because the wrapper (the buildEnv call) needs to be duplicated. Any reason why we do not always apply it ? Worst case the user expression needs to be coaxed a bit to provide binutils, isClang and targetPrefix. Not really hard.

A tricky one is also wrapCCWith. Not sure how it works in mixed setups.

Finally, I could use some help writing tests in this new repo layout.

@avdv
Copy link
Member

avdv commented Jun 29, 2022

Nice! You beat me to it... 😄

Note, that this is not only useful for cross-compilation, but also when using a static CC based on musl for example (think pkgs.pkgsStatic.clangStdenv.cc for example).

I'll have a deeper look when I found some time later...

@aherrmann
Copy link
Member

Nice! Thank you for looking into this!

But providing such an expression is difficult because the wrapper (the buildEnv call) needs to be duplicated. Any reason why we do not always apply it?

Mainly, when we created this, we didn't know how much liberty users would need to override the details of the toolchain, e.g. see here. However, looking at the shape this is taking, and how things like binutils can be bundled with cc, it may well be fine to hard-code the buildEnv and only take the cc as a parameter.

Finally, I could use some help writing tests in this new repo layout.

Where are you encountering difficulties? The tests for the cc-toolchain have been moved here.

@aherrmann
Copy link
Member

@layus What's the status on this one? What do you need to push it over the finish line?

@benradf benradf self-requested a review as a code owner August 9, 2023 08:50
@benradf
Copy link
Member

benradf commented Aug 9, 2023

@layus @avdv I think I resolved the merge conflict between this PR and Pass the unwrapped cc to wrapCCWith appropriately, but let me know if I made a mistake.

@benradf benradf requested a review from avdv August 9, 2023 09:12
Copy link
Member

@avdv avdv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@benradf benradf merged commit 98daf39 into master Aug 10, 2023
10 checks passed
@benradf benradf deleted the cross-cc-toolchain branch August 10, 2023 08:34
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.

4 participants