build: add a Swift Package Manager manifest - #40
Open
zunda-pixel wants to merge 1 commit into
Open
Conversation
Lets a project on Apple platforms depend on the codec directly, which is the only way to reach it from Swift: no Apple framework decodes Speex, so an application that has to read it has to build this. Nothing under libspeex/ changes, and the manifest adds no file that configure also generates, so the same checkout still builds with autotools or meson afterwards. - What config.h would have carried is passed as -D instead: floating point with smallft, the pair a bare ./configure settles on (configure.ac:215-250), and VAR_ARRAYS, since clang has variable-length arrays and the codec then needs neither alloca nor a preallocated scratch area. - speex_config_types.h is not needed either. On Apple platforms speex_types.h defines the four sized types itself, in its __APPLE__ && __MACH__ branch. That branch is also why the manifest claims no other platform: elsewhere the same header reaches for the generated one. Three things in it are less obvious than they look. - The sources are listed rather than walked, and the list is what a bare ./configure builds: libspeex_la_SOURCES plus the smallft.c that FFTSRC resolves to. Writing it out keeps the manager away from the rest of the repository — the other build systems, the ports, the documentation. - Directories are excluded even so, because the manager walks the target's directory for resources whatever `sources` says, and stops on the localized ones under macosx/ to ask for a default localization. - The target is called libspeex rather than speex. Given the latter, the manager takes include/speex/speex.h for an umbrella header and then rejects the module for leaving the neighbouring headers out; under any other name it treats include/ as an umbrella directory, which is what those headers are. Only libspeex is offered. speexdsp is its own repository and would need the same there.
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
1 participant
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.
Adds a
Package.swiftso a project on Apple platforms can depend on libspeex directly. That is the only way to reach the codec from Swift: no Apple framework decodes Speex, so an application that has to read it has to build this.Two files, both new —
Package.swiftand a.gitignorefor/.build/,/.swiftpm/,/DerivedData/. Nothing underlibspeex/changes, and the manifest adds no file thatconfigurealso generates, so the same checkout still builds with autotools or meson afterwards. I have been building it both ways in one tree.What replaces config.h
Passed as
-Drather than written to a file:FLOATING_POINT,USE_SMALLFT./configuresettles on (configure.ac:215-250)VAR_ARRAYSallocanor a preallocated scratch area is neededEXPORT=speex_config_types.his not needed at all: on Apple platformsspeex_types.hdefines the four sized types itself, in its__APPLE__ && __MACH__branch.Three things that are less obvious than they look
The sources are listed rather than walked, and the list is exactly what a bare
./configurebuilds —libspeex_la_SOURCESplus thesmallft.cthatFFTSRCresolves to, 31 files. Writing it out keeps the manager away from the rest of the repository: the other build systems, the ports, the documentation.Directories are excluded even so. The manager walks the target's directory looking for resources whatever
sourcessays, and stops on the localized ones undermacosx/to ask for a default localization. Only directories are named, because the list is short and stable, whereas the loose files at the root come and go.The target is called
libspeex, notspeex. Given the latter, the manager takesinclude/speex/speex.hfor an umbrella header and then rejects the module for leaving the neighbouring headers out. Under any other name it treatsinclude/as an umbrella directory, which is what those headers are.Scope
__APPLE__ && __MACH__branch above is what makes the generated header unnecessary; elsewherespeex_types.hreaches forspeex_config_types.h, so building on Linux would need either that file or a source change. I left both out to keep this to a manifest.fftwrap.corvorbis_psy.c. Neither is inlibspeex_la_SOURCESorlibspeex/meson.build's default, andvorbis_psy.cis empty withoutVORBIS_PSYCHO.How it has been used
A Pebble companion app for iOS and macOS decodes the watch's Speex voice frames with this, built for both platforms. Its decoder tests — a recording from the watch round-tripped to samples, frame sizing, and the two refusal paths — pass against this manifest.