8000 When using xcode discover tests before test to avoid running unsigned code by JonnyPtn · Pull Request #3647 · SFML/SFML · GitHub
[go: up one dir, main page]

Skip to content

Conversation

@JonnyPtn
Copy link
Contributor
@JonnyPtn JonnyPtn commented Jan 24, 2026

Currently building the unit tests with Xcode 15+ will fail, as catch_discover_tests tries to run the test as a post-build step which is before it's. been codesigned, see https://gitlab.kitware.com/cmake/cmake/-/issues/21845

I can't explain why this works on the GitHub runners, as far as I can tell the commands are the same. I would guess they may have gatekeeper disabled but I can't find anything to verify this

I don't believe it's any particular setting on my machine, but would be good for someone else to double check (@Rosme / @ChrisThrasher ?) - should reproduce if you just generate sfml projects for Xcode and try to build a test target

@github-project-automation github-project-automation bot moved this to Planned in SFML 3.1.0 Jan 26, 2026
@eXpl0it3r eXpl0it3r added this to the 3.1 milestone Jan 26, 2026
@eXpl0it3r eXpl0it3r moved this from Planned to In Review in SFML 3.1.0 Jan 26, 2026
@Rosme
Copy link
Contributor
Rosme commented Jan 27, 2026

Sorry for the delay.

Using xcode 26.1.1, I can't reproduce your issue @JonnyPtn .
All test suites build and complete fine. I used your branch of this PR.
Also using an Intel machine.

Something on your end I think.

@JonnyPtn
Copy link
Contributor Author
JonnyPtn commented Jan 27, 2026

Sorry I meant confirm it reproduced on master, this PR fixes it so good that's confirmed :D

Just want to make sure I'm fixing a real bug as the CI on master isn't having an issue

Also would likely need a clean build to reproduce on master after you switch, as otherwise the binary will still be signed from your build of this branch

@Rosme
Copy link
Contributor
Rosme commented Jan 28, 2026

Not gonna lie. I'm confused. The master branch of SFML, I can configure, generate, build and run all the tests. Your master branch, I can't generate.

So all that to say, SFML master is fine, your master is broken, your PR is fine.

Can't explain.

@JonnyPtn
Copy link
Contributor Author
JonnyPtn commented Jan 28, 2026

Ignore master on my fork that's unrelated and likely very out of date

So if I run these commands on current SFML master:

rm -rf build
cmake --preset dev -GXcode
cmake --build build --target test-sfml-system

then it fails with the following output:

Ld /Users/jonny.paton/projects/sfml/build/bin/Debug/test-sfml-system normal (in target 'test-sfml-system' from project 'SFML')
    cd /Users/jonny.paton/projects/sfml
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -Xlinker -reproducible -target arm64-apple-macos13.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.1.sdk -O0 -L/Users/jonny.paton/projects/sfml/build/build/EagerLinkingTBDs/Debug -L/Users/jonny.paton/projects/sfml/build/bin/Debug -F/Users/jonny.paton/projects/sfml/build/build/EagerLinkingTBDs/Debug -F/Users/jonny.paton/projects/sfml/build/bin/Debug -filelist /Users/jonny.paton/projects/sfml/build/build/test-sfml-system.build/Debug/Objects-normal/arm64/test-sfml-system.LinkFileList -Xlinker -object_path_lto -Xlinker /Users/jonny.paton/projects/sfml/build/build/test-sfml-system.build/Debug/Objects-normal/arm64/test-sfml-system_lto.o -Xlinker -no_deduplicate -Xlinker -dependency_info -Xlinker /Users/jonny.paton/projects/sfml/build/build/test-sfml-system.build/Debug/Objects-normal/arm64/test-sfml-system_dependency_info.dat -Wl,-search_paths_first -Wl,-headerpad_max_install_names /Users/jonny.paton/projects/sfml/build/test/Debug/libsfml-test-main.a /Users/jonny.paton/projects/sfml/build/lib/Debug/libsfml-system-s-d.a /Users/jonny.paton/projects/sfml/build/_deps/catch2-build/src/Debug/libCatch2Maind.a /Users/jonny.paton/projects/sfml/build/_deps/catch2-build/src/Debug/libCatch2d.a -Xlinker -no_adhoc_codesign -o /Users/jonny.paton/projects/sfml/build/bin/Debug/test-sfml-system

PhaseScriptExecution CMake\ PostBuild\ Rules /Users/jonny.paton/projects/sfml/build/build/test-sfml-system.build/Debug/Script-24994A5DA7072A95E4959E0F.sh (in target 'test-sfml-system' from project 'SFML')
    cd /Users/jonny.paton/projects/sfml
    /bin/sh -c /Users/jonny.paton/projects/sfml/build/build/test-sfml-system.build/Debug/Script-24994A5DA7072A95E4959E0F.sh
CMake Error at /Users/jonny.paton/projects/sfml/build/_deps/catch2-src/extras/CatchAddTests.cmake:82 (message):
  Error listing tests from executable
  '/Users/jonny.paton/projects/sfml/build/bin/Debug/test-sfml-system':

    Result: Subprocess killed
    Output: 

Call Stack (most recent call first):
  /Users/jonny.paton/projects/sfml/build/_deps/catch2-src/extras/CatchAddTests.cmake:234 (catch_discover_tests_impl)


Command PhaseScriptExecution failed with a nonzero exit code

that's the post build step from catch_discover_tests failing without any output, but is due to the binary not being code signed - see the -no_adhoc_codesign command on the linker command

Is that the same as you're seeing? I'll try and find another Mac to test on as well, I know gatekeeper behaves slightly differently on Intel Macs so if you're running the same commands and seeing the same output but succeeding then it could be that

edit: Upstream catch issue catchorg/Catch2#2411 indicates it's not an issue on intel, which would explain why you can't reproduce @Rosme

@JonnyPtn
Copy link
Contributor Author

Confirmed this is only an issue when on an arm mac, and building arm binaries - If i build x64 locally it's fine

We don't actually test arm xcode builds in github CI which is probably an oversight, but I've tested adding that and still haven't been able to reproduce the issue there - No matter what I try it seems like they are just configured to allow running unsigned code.

Regardless, all the evidence (CMake and catch issues, as well as my own reproduction) points to it being a real issue, so while it might still be good to get a second opinion I'm as confident as I can be that this is a worthwhile change (not least because I'll struggle to continue contributing SFML mac fixes without it...)

@Rosme
Copy link
Contributor
Rosme commented Jan 28, 2026

Ah yeah, well okay, that explains it.

Interesting though it's only an issue on intel. I do think it's worth the fix. And it could very well be it allows running unsigned code for dev purpose to simplify things.

I'm confident that you've done what needed to be done, and I'd say let's push that.

As for not testing arm builds, that should be fixed in my opinion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: In Review

Development

Successfully merging this pull request may close these issues.

3 participants

0