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

Support x86_64-darwin in flake #586

Merged
merged 5 commits into from
Jan 3, 2023
Merged

Support x86_64-darwin in flake #586

merged 5 commits into from
Jan 3, 2023

Conversation

mtoohey31
Copy link
Contributor

This pull request adds support for the x86_64-darwin system to the flake, as well as a list-keyboards package for that platform. It does the same thing as #566 except for master.

@MuhammedZakir
Copy link
Contributor

About submodules: executing git submodule update as a pre-build hook is better, right? Submodule is necessary when building, so the current suggest way doesn't feel good. :-( Although if that's the only way right now, then leave it as is.

@mtoohey31
Copy link
Contributor Author

About submodules: executing git submodule update as a pre-build hook is better, right? Submodule is necessary when building, so the current suggest way doesn't feel good. :-( Although if that's the only way right now, then leave it as is.

That would be much nicer, but it doesn't look like Nix copies the .git directory to the store when it clones sources, so I don't think that will work. There's two alternatives I can come up with:

  1. We add the karabiner submodule as a flake input too and copy it into place during the build. I don't really like this option because it will require us to keep the submodule version in sync with the flake input, and things could get really messy if someone does pull the flake in with submodules.
  2. I could add a phase early on that checks if submodules are present when building for darwin. It won't prevent people from having to use the wierd submodule query parameter, but it will at least tell them what to do if they don't use it.

I lean towards the second option, does that sound ok to you?

@MuhammedZakir
Copy link
Contributor

Sorry for the late response.

I lean towards the second option, does that sound ok to you?

Go ahead with 2nd option. :-)

@mtoohey31
Copy link
Contributor Author

Sorry for the late response.

I lean towards the second option, does that sound ok to you?

Go ahead with 2nd option. :-)

No worries, added in f25660a!

@slotThe
Copy link
Member

slotThe commented Aug 11, 2022

@MuhammedZakir @mtoohey31 is this in a mergeable state now? I won't pretend to know about nix on MacOS, so opinions are very welcome :)

@mtoohey31
Copy link
Contributor Author

Yes, it should be good to go. It should be merged at the same time as #566 though, and the way we left things there was that we'd wait for a little bit to see if anyone else had feedback before merging, as per this comment: #566 (comment). There might not be anyone else to give feedback though; the KMonad + Nix + MacOS niche is probably quite small 🙂.

@rafaelliu
Copy link

I have a M1 mac running Monterey and dext, @mtoohey31 fork installed without a flaw. Been running kmonad for a day now, no issues.

Just adding "aarch64-darwin" to supportedSystems was enough, should it be added to the PR?

@mtoohey31
Copy link
Contributor Author

Great to hear @rafaelliu, thanks for testing it! I've added that in 1935809.

@mtoohey31
Copy link
Contributor Author

I've been using this branch almost daily since I created the PR, and things seem to be working fine. I've just rebased both this branch and the one for #566. Would it be possible to merge these two PRs soon?

@slotThe
Copy link
Member

slotThe commented Jan 2, 2023

@mtoohey31 Yes! I'll try to get to this before Friday (if not please nag :)

@mtoohey31
Copy link
Contributor Author

Great, thank you!

@slotThe slotThe merged commit 1ee4644 into kmonad:master Jan 3, 2023
@slotThe
Copy link
Member

slotThe commented Jan 3, 2023

Thank you! Sorry for not seeing/getting to this sooner, I've been pretty swamped with other projects

@mtoohey31
Copy link
Contributor Author

No worries, thanks again!

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.

None yet

4 participants