Skip to content

Use consistent Python in MacOS GitHub runner#5331

Merged
skef merged 3 commits intofontforge:masterfrom
iorsh:ci_macos
Jan 1, 2024
Merged

Use consistent Python in MacOS GitHub runner#5331
skef merged 3 commits intofontforge:masterfrom
iorsh:ci_macos

Conversation

@iorsh
Copy link
Copy Markdown
Contributor

@iorsh iorsh commented Dec 31, 2023

MacOS 11 GitHub runner has multiple instances of Python 3.12 installed, with different subversions. We shall use the instance found by CMake for all tests, including smoke.

@JoesCat
Copy link
Copy Markdown
Contributor

JoesCat commented Dec 31, 2023

Looks good. Mac resolved.

Comment thread CMakeLists.txt Outdated
add_subdirectory(contrib)
if(ENABLE_PYTHON_SCRIPTING_RESULT)
add_subdirectory(pycontrib)
write_file("CMake_Python3_EXECUTABLE" "${Python3_EXECUTABLE}")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can you say more about this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Added comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Oh, sorry, the comment is great but when I say "can you say more about" in the context of these PR reviews, I just mean to me, in these messages. I'll say something about a "comment" when I think that's needed.

What I'm wondering about here is the context and the scope. Since we're changing the top-level CMakeLists in a way not protected by "APPLE" we need to make sure this doesn't have any unfortunate implications in other contexts.

So:

  1. The CMake documentation seems to think write_file is deprecated since version 3, so we should probably change this to a file(WRITE semantic
  2. Given that we only use this file in the mac github workflow (as far as I can tell) we should probably have this in a if(APPLE) check in the CMakeLists.txt, right?

Other than that, I see no big harm in adding a vaguely mysterious build artifact. I can't see how it would get installed or otherwise confuse things.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ah, I see... Well, the more comments the better anyway
Regarding your specific reservations:

  1. I tried file(WRITE, and it just didn't work. It produced no file nowhere, and I didn't bother to research it in depth.
  2. As a general rule I prefer to expose such hacks, so that they serve as a sort of canary. If this file causes issues on other platform, it likely means it's not good on Mac either, but it's bad influence is somehow obscured. So I prefer to create it unconditionally, and if there are problems, maybe think of a different and cleaner solution. I understand that it's mostly my personal taste, and can confine it to APPLE if you still prefer that.

@skef
Copy link
Copy Markdown
Contributor

skef commented Jan 1, 2024

OK, I made my picky little changes and it seems to work fine, so I'm merging this.

@skef skef merged commit 6be8960 into fontforge:master Jan 1, 2024
@iorsh
Copy link
Copy Markdown
Contributor Author

iorsh commented Jan 1, 2024

OK, I made my picky little changes and it seems to work fine, so I'm merging this.

🤷‍♂️ Magic... Thanks!

@iorsh iorsh deleted the ci_macos branch January 2, 2024 16:55
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.

3 participants