0683dde5d3
cargo-xwin drives the Windows MSVC cross-compile via clang-cl, under which CMake sets MSVC=1 — causing libopus 1.3.1's `if(NOT MSVC)` guards to skip the per-file `-msse4.1` / `-mssse3` COMPILE_FLAGS that its x86 SIMD source files need. Clang-cl (unlike real cl.exe) still honors Clang's target-feature system, so those files then fail to compile with "always_inline function '_mm_cvtepi16_epi32' requires target feature 'sse4.1'" errors across silk/NSQ_sse4_1.c, NSQ_del_dec_sse4_1.c, and VQ_WMat_EC_sse4_1.c. Earlier attempts to fix this downstream (cargo-xwin toolchain file, override.cmake CMAKE_C_COMPILE_OBJECT <FLAGS> replace, CFLAGS env vars) all failed because cargo-xwin rewrites override.cmake from scratch on every `cargo xwin build` invocation and cmake-rs's -DCMAKE_C_FLAGS= assembly happens before toolchain FORCE sets propagate. Fixing it upstream at the source: vendor audiopus_sys 0.2.2 into vendor/audiopus_sys, patch its bundled opus/CMakeLists.txt to introduce an MSVC_CL var (true only when CMAKE_C_COMPILER_ID == "MSVC", i.e. real cl.exe), and flip the eight `if(NOT MSVC)` SIMD guards to `if(NOT MSVC_CL)`. Clang-cl then gets the GCC-style per-file flags and the SSE4.1 sources build cleanly. Also flip the `if(MSVC)` global /arch block at line 445 to `if(MSVC_CL)` so only cl.exe applies /arch:AVX and clang-cl relies purely on per-file flags (no global/per-file mixing). Wire via [patch.crates-io] in the workspace root Cargo.toml; the patch is resolved relative to the workspace root as `vendor/audiopus_sys`. Upstream context: xiph/opus#256, xiph/opus PR #257 (both stale). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
63 lines
1.9 KiB
Markdown
63 lines
1.9 KiB
Markdown
# Contributing
|
|
|
|
Everyone is welcome to get involved, may it be a pull request, suggestion, bug
|
|
report, or a textual improvement! : )
|
|
|
|
The language applied in this repository is British English.
|
|
|
|
## Contributions
|
|
|
|
Contributions to `audiopus_sys` should be first discussed up via an issue and then
|
|
implemented via pull request.
|
|
Issues display development-plans or required brainstorming, feel free to ask,
|
|
suggest, and discuss!
|
|
The `master`-branch contains the latest release.
|
|
|
|
## Comments & Documentation Style
|
|
|
|
- Comments are placed the lines before the related code line, not on the same
|
|
line.
|
|
|
|
- Write full sentences in British English.
|
|
|
|
- `unsafe` must always be reasoned and their soundness must be proven via a
|
|
comment.
|
|
|
|
- Use Rust intra-doc-links paths to refer Rust items in documentation:
|
|
`[name](crate::module::struct::method)`.
|
|
|
|
- If code ends up difficult, try to simplify it, if unavoidable, explain code
|
|
with comments. Prefer explicit variable naming instead of abbreviations.
|
|
|
|
## Commit Style
|
|
|
|
Write full sentences in British English.
|
|
|
|
Commits should describe the action being peformed.
|
|
|
|
Example:
|
|
- *Fix deadlock for events.*
|
|
- *Correct grammar in `command`-example.*
|
|
|
|
## Pull Request Checklist
|
|
|
|
- Make sure to open an issue prior working on a problem or ask on existing
|
|
issue be assigned.
|
|
|
|
- If a pull requests breaks the current API, use the `breaking-changes`-branch,
|
|
otherwise `stable-changes`.
|
|
|
|
- Commits shall be as small as possible, compile, and pass all tests.
|
|
|
|
- Make sure your code is formatted with `rustfmt` and free of lints,
|
|
run `cargo fmt` and `cargo clippy`.
|
|
|
|
- If you fixed a bug, add a test for that bug. Unit tests belong inside the
|
|
same file's `mod` named `tests`, integrational tests belong inside the
|
|
`tests`-folder.
|
|
|
|
- Last but not least, make sure your planned pull request merges cleanly,
|
|
if it does not, rebase your changes.
|
|
|
|
If you have any questions left, please reach out via the issue system : )
|