Move mp4parse_capi's build_ffi_test to new test_ffi crate. #199
Conversation
This file contains 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
kinetiknz
force-pushed
the
ffi_build_reworked
branch
3 times, most recently
from
513dcf8
to
6477d4b
Compare
|
This works on windows-msvc locally, but windows-gnu (Travis default) fails due to rust-lang/rust#47048, I think. I don't see an easy way to address this right now, but switching our Windows builds to windows-msvc will avoid this and is more realistic target anyway. |
kinetiknz
force-pushed
the
ffi_build_reworked
branch
11 times, most recently
from
72e69d1
to
396897b
Compare
SingingTree
approved these changes
Mar 10, 2020
kinetiknz
force-pushed
the
ffi_build_reworked
branch
from
396897b
to
6a34b4a
Compare
The existing process invoked a Makefile from a Rust test, building test.cc and a statically linkable mp4parse_capi, then running a series of C API tests. This wasn't very portable due the reliable on a Makefile, which also made assumptions about the layout of cargo's build artifacts. The new process introduces a new crate (test_ffi) and changes mp4parse_capi to additionally build as a cdylib. A build.rs in test_ffi builds test.cc (which must now be written with a simple library API, rather than as a binary with a main() due to cc-rs limitations) into a static libtest, which is then linked to test_ffi's Rust binary in main.rs. test.cc is now split into run_main for the binary dumping tool and test_main for the API tests. `cargo run -p test_ffi path/to/a.mp4` invokes run_main, and test_ffi's ffi_test invokes test_main. Fixes mozilla#197
The Travis default of windows-gnu suffers from rust-lang/rust#47048, I think. I don't see an easy way to address this right now, but switching our Windows builds to windows-msvc will avoid this and is more realistic target anyway.
This reverts commit cd179f2.
kinetiknz
force-pushed
the
ffi_build_reworked
branch
from
d1bab09
to
edd4d64
Compare
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.
The existing process invoked a Makefile from a Rust test, building test.cc
and a statically linkable mp4parse_capi, then running a series of C API
tests. This wasn't very portable due the reliable on a Makefile, which also
made assumptions about the layout of cargo's build artifacts.
The new process introduces a new crate (test_ffi) and changes mp4parse_capi
to additionally build as a cdylib. A build.rs in test_ffi builds
test.cc (which must now be written with a simple library API, rather than as
a binary with a main() due to cc-rs limitations) into a static libtest,
which is then linked to test_ffi's Rust binary in main.rs.
test.cc is now split into run_main for the binary dumping tool and test_main
for the API tests.
cargo run -p test_ffi path/to/a.mp4invokes run_main,and test_ffi's ffi_test invokes test_main.
Fixes #197