Repository navigation
build(xcframework): nest the CFFmpeg module map under Headers/CFFmpeg/ - #61
Merged
Merged
Conversation
Xcode copies every static xcframework's Headers/ into one
Products/<config>/include/, so a root module.modulemap collides with any
other package that ships one there. Lume hits this once it links
AetherEngine, whose LibDovi xcframework also puts module.modulemap at the
Headers root ("Multiple commands produce .../include/module.modulemap").
CFFmpeg.h, CFFmpegShim.h and module.modulemap now go to Headers/CFFmpeg/;
lume_ffmpeg/ stays at the root, where CFFmpeg.h's <lume_ffmpeg/...>
includes resolve against the Headers search path.
The published v0.3.0 artifact still has the old layout: a release has to
attach a rebuilt FFmpeg.xcframework.zip before Package.swift's URL and
checksum move to it.
9 of 12 tasks
dustintinsley
pushed a commit
to dustintinsley/Streamen
that referenced
this pull request
Nov 4, 2026
AetherEngine (superuser404notfound/AetherEngine, exact 7.53.1) joins KSPlayer, VLCKit, AVPlayer and LumeEngine. It is declared last, so existing priority lists append it and KSPlayer stays the default. iOS, macOS and tvOS only; visionOS never links it. Lume reaches it only through the in-repo dynamic package LumeAetherBridge: importing it directly clashes with KSPlayer's FFmpegKit Libav* modules. Package traits stay off. Licences: LGPL-3 + App Store exception, FFmpegBuild LGPL 2.1 dynamic, libdovi MIT; notices in CreditsInfo. - Curated device-local options under player.aether.*, with iOS/macOS and tvOS settings screens, including Aether's own tvOS Match Content toggle - Full-screen playback, Multiview tiles and guide previews (embedded: muted, secondary output, no display criteria), full PiP, no timeshift - macOS gets com.apple.security.network.server for Aether's loopback HLS server - Shared player helpers replace per-engine copies: subtitle cue overlay, invisible button style, menu/play-pause presses, rate label, macOS hover reveal, Now Playing transport, engine failure policy, tile reconnects - 39 strings in all 10 languages; tests for options, load mapping, failure classification and engine priority Needs bilipp/LumeEngine#61 (CFFmpeg module map nested under Headers/CFFmpeg/), or LibDovi's module.modulemap collides with LumeEngine's.
naishyadav
pushed a commit
to naishyadav/LumeEngine
that referenced
this pull request
Nov 9, 2026
The v0.5.0 release attaches an FFmpeg.xcframework.zip built with the nested CFFmpeg module map (bilipp#61). Consumers without BinaryDependencies/ resolve this artifact; the v0.3.0 one still has the root module.modulemap that collides with LibDovi's in a host that links both.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Lume is adding AetherEngine as a fifth engine. AetherEngine pulls in LibDovi, whose static
Dovi.xcframeworkalso putsmodule.modulemapat the root ofHeaders/. Xcode copies every static xcframework'sHeaders/into oneProducts/<config>/include/, so the app build stops with "Multiple commands produce …/include/module.modulemap". LibDovi is third-party, so the fix goes here.Change
build/scripts/make-xcframework.shnow stagesCFFmpeg.h,CFFmpegShim.handmodule.modulemapinHeaders/CFFmpeg/.lume_ffmpeg/stays at theHeaders/root, whereCFFmpeg.h's<lume_ffmpeg/…>includes resolve against the Headers search path. No FFmpeg source, configure flag or patch changes.Verification
BinaryDependencies/FFmpeg.xcframeworkto the new layout.swift buildsucceeds.CFFmpegmodule still resolves.Release follow-up (not done here)
The published
v0.3.0FFmpeg.xcframework.zipstill has the old layout, so CI and consumers on the URL path keep the old layout until a release attaches a rebuilt artifact andPackage.swift'sffmpegArtifactURLand checksum move to it. Use the two-step flow inAGENTS.md. Lume CI and sideload builds hit the clash until then.Related
Paired with bilipp/Lume's AetherEngine PR (
feature/add-support-for-aetherengine-https).