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

Fix shaders not copying to final build on macOS for non Xcode builds (2) #1908

Merged
merged 3 commits into from
May 21, 2024

Conversation

smilediver
Copy link
Contributor

Describe your changes

I attempted to fix this in #1631, but it works only if the shaders were already built (since it scans the runtime/axslc dir for files), so you have to rerun CMake again to pick them up. This PR fixes that.

How it works: when ax_target_compile_shaders() is called on an app or library target to compile the shaders, it sets AX_COMPILED_SHADERS variable on the target. The variable contains a list of compiled shaders. When ax_setup_app_config() is called on the app target, it recursively iterates all targets being linked, extracts the list of all shaders from them, and adds them as resources.

@halx99
Copy link
Collaborator

halx99 commented May 21, 2024

Note: cmake 3.28+ is strong recommanded in mac/ios/tvos, the new cmake feature EMBED_RESOURCES will auto sync all compiled shaders in to deploy target

@smilediver
Copy link
Contributor Author

Hmm.. CI osx builds show up as green, but they have actually failed.

@smilediver
Copy link
Contributor Author

Note: cmake 3.28+ is strong recommanded in mac/ios/tvos, the new cmake feature EMBED_RESOURCES will auto sync all compiled shaders in to deploy target

Do you mean XCODE_EMBED_RESOURCES? We do use 3.29, but this fix is for non Xcode builds, ie for Ninja.

@halx99
Copy link
Collaborator

halx99 commented May 21, 2024

Note: cmake 3.28+ is strong recommanded in mac/ios/tvos, the new cmake feature EMBED_RESOURCES will auto sync all compiled shaders in to deploy target

Do you mean XCODE_EMBED_RESOURCES? We do use 3.29, but this fix is for non Xcode builds, ie for Ninja.

yes, I have never use non-xcode for apple platforms to build axmol yet.

@halx99
Copy link
Collaborator

halx99 commented May 21, 2024

strange, why the patch cause glfw build error

@smilediver
Copy link
Contributor Author

strange, why the patch cause glfw build error

I think this is due to CMake 3.20 requirement and adding enable_language(OBJC OBJCXX). After CMake 3.16 I think it needs full language specification like:

if(APPLE)
    enable_language(C CXX OBJC OBJCXX)
else()
    enable_language(C CXX)
endif()

Pushed fix, lets see if this will fix it.

@smilediver
Copy link
Contributor Author

Looks like everything is working now.

@halx99
Copy link
Collaborator

halx99 commented May 21, 2024

strange, why the patch cause glfw build error

I think this is due to CMake 3.20 requirement and adding enable_language(OBJC OBJCXX). After CMake 3.16 I think it needs full language specification like:

if(APPLE)
    enable_language(C CXX OBJC OBJCXX)
else()
    enable_language(C CXX)
endif()

Pushed fix, lets see if this will fix it.

What about add to https://github.com/axmolengine/axmol/blob/dev/cmake/Modules/AXConfigDefine.cmake#L214 instead adding to project cmake one by one?

@halx99 halx99 added this to the 2.1.3 milestone May 21, 2024
@halx99 halx99 added the enhancement New feature or request label May 21, 2024
@halx99 halx99 merged commit ddeb14c into axmolengine:dev May 21, 2024
15 checks passed
@smilediver smilediver deleted the fix_shader_build branch May 22, 2024 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants