This is not working because spawning cargo for each tests is too slow,
and cannot even re-use the same target directory because it would block
on the cargo lock file. and rebuild all the dependences because of
different flags
* Remove the dependency to the rust frontend and library from the test
driver. Tests are compiled and run as standalone programs.
* Add diagnostics for the initial cargo run for the dependencies.
Collect all tests are build time in build.rs and generate Rust code that
uses #[test] annotated functions. This gives nice reporting and the
ability to run individual tests.
* Fix text-file-busy error when running the binary by replacing the use
of named temp file with simply using the input source file and the
extension replaced. A scope guard make sure to also delete the binary.
* Fix hard-coded library dependencies by sharing code with the cmake
xtask that needs the same list.
This extracts a compiler command line from the cc crate, runs the
compiler and tries to run the resulting binary. Unfortunately the latter
fails still.
The objective is to have a bunch of .60 files with annotations inside
and the test harness picks them up and runs them through the Rust and
C++ frontend.
Don't try to determine the native libs dependency *and* the artifact
collection in one go by setting RUSTFLAGS, as that causes everything to
be rebuilt over and over again.
Instead, go back to invoking rustc once to determine the native libs
dependencies.
Call cargo only once by building the target package (gl renderer) right
away and passing the RUSTFLAGS to get the native library dependency.
Suggested by Olivier :)
The cargo target directory tree is now populated with a cmake package
file and that's also installed into the prefix specified with the cargo
cmake xtask.
As a consequence, the cpptest example can be built by first building the
cmake package:
cargo xtask cmake
or
cargo xtask cmake --release --target some-triplet)
or
cargo xtask cmake --release --prefix /somewhere --install
and then run cmake in the cpptest example with a prefix path:
-DCMAKE_PREFIX_PATH=/where/you/installed/it or simply
-DCMAKE_PREFIX_PATH=../../target/debug for example.
Pending still is the sixtyfps compiler tool installation and discovery.
Use a full prefixed name (sixtyfps_rendering_backend_gl) to ensure that
the created static lib can be installed without file conflicts (libgl is
not a unique name).
This is done by calling cargo with json output to build the libraries,
collect the .a files, extract the native libraries needed for final
linkage and pass all that to a CMake project that cobbles together the
.a files into a propery cmake target with include paths, etc.
The objective is to automatically create a propery cmake module, with a
FindSixtyFPSConfig.cmake, corresponding targets .cmake files, etc. This
should encapsulate the build profile (debug vs. release) and also allow
making the choice of shared vs. static transparent.
Unfortunately it does not seem to be possible to easily combine different
crates into one cdylib crate that can re-export symbols from the
statically linked rust crates (cbindgen generated, as well as manual
extern "C").
That means for the dynamic case (not cared for right now), we're going
to need to create either one cdylib per crate that has public symbols or
manually re-export the symbols.
For the static case, linking just against the "last crate" in the chain
(the gl renderer backend) is sufficient to pull in all needed symbols.
In addition for the static case we need to specify the linkage of some
external libraries. This can be extracted manually via
cargo rustc -p gl -- --print=native-static-libs
for example. For now that's in the changed CMakeLists.txt, but the plan
going forward is to automate this extraction in an xtask, to paste that
into the cmake target.
Finally, both linkage scenarios require access to the headers. This is
for now solved by generating them simply in an include sub-directory of
the build folder ($root/target/${profile}/include).
