-
Notifications
You must be signed in to change notification settings - Fork 13
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
does macos building work? #134
Conversation
This is trying to build for GCC on clang, I think? |
macos should have the gcc frontend for llvm installed as well. |
Hi @lgray, I also gave a shot at this yesterday but I didn't get it to work. I was actually able to get it to compile with clang by replacing
Unfortunately, I won't have time to troubleshoot this more (today at least). |
Actually, I almost got this to work: https://github.com/chrispap95/fastjet/actions/runs/3392170281/jobs/5638053408 |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
This is a nice to have not a need to have so we can take care of this one with some leisure. |
This morning I found some time to investigate this a bit more. The status is the following:
I believe that we have two options:
|
Current status: everything builds & tests successfully except for |
You should not use gcc on macOS. That will create a mass of problems. You can (and should) set MACOSX_DEPLOYMENT_TARGET to something that supports C++17 (10.12-10.14, depending on how many C++17 features you use). (Edit: Ahh, didn't real all the messages, okay). |
just tagging @jpata who was interested in this as well. @chrispap95 is there anything in particular that others can help with to move this forward? |
So now this fails for the same reason #153 fails. Between, those 2 cibuildwheel versions it seems that the docker image changes. Since this problem now propagates to MacOS, I am wondering whether this is caused by some dependency update (e.g. swig). I just checked the two images and indeed swig goes from Now, for MacOS, apart from this new issue which seems universal, I had it almost working. Only the very last check was failing for some strange reason and I never got to debug it. It seems that we have to solve the issue with |
fastjet will compile with swig back to version 2. The underscores to dots problem is recent v4 issue. If we can pin to an older swig in the package managers we can get around it (this is usually possible). |
Actually, the problem here is those |
Oh, weird. Kind of surprised swig would change the behavior of something like that. Good find. :-) |
oh, that's interesting. I guess now we can have working MacOS wheels! |
@chrispap95 that's great! Is there anything left to do for this PR? |
@jmduarte not much. I will push a commit to build wheels as well for MacOS and if this is also successful then we can merge and publish. |
Interesting. This single failure is similar to the old failure (before awkward 2) but not exactly the same. The same test fails but for different reasons. The old test was failing because the offset array was garbage. This time part of the result is empty??? |
It's done. It seems that I forgot to remove 2 of those dangerous reallocs, that I inserted into the code, and they were causing the offset array to pick up noise. We should be able to publish MacOS wheels after merging this + methods |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, this looks great! I just tested it on my MacBook Pro with macOS 13.0.1, python 3.11.0 and the generated wheel worked perfectly out of the box!
No description provided.