Switch back to toml_edit for the Cargo.toml check, as that makes it easy
to also apply fixes -- the formatting is preserved.
This also removes the indirect serde_derive dependency that may be
causing problems on macOS sometimes.
Also, now that the cargo test doesn't trigger a build anymore, the use
of toml_edit here should not cause the problem mentioned in commit
ab89fcb69a anymore -- fingers crossed.
This reverts commit 0bb904e10a and
re-introduces the markdown table support extension. The resulting table
by default is too wide in the "responsive" read-the-docs theme, but with
a CSS tweak it becomes readable.
Markdown tables are much easier to deal with and this way we can also
include references within the tables.
Tear it out of the CMakeLists.txt and instead run it via
cargo xtask cppdocs
This allows the build_and_test step in the CI to only run cmake for the
library/header related bits and the docs_and_demos step to only generate
docs and not require a full host build of the library (as cargo xtask
cmake would otherwise do).
Currently the Qt backend still redirect everything to the GL backend,
but the goal is to use QPainter and QWindow
This also adds a "default" backend, whose goal is to select the proper
backend at compile time
Doxygen's markdown support can't quite deal with the Github flavor,
the language reference looks terrible.
So instead, this change switches to using Sphinx,
with two extensions that call Doxygen for us and allow including markdown.
The result is a read-the-docs themed sphinx site that includes search even
in the language reference.
- Give all the sixtyfps-* create a 0.0.1 version
- Make sure that the internal dependences are using the exact same version
(so "=0.0.1")
- Add the description/homepage/repository fields in the .toml files
- Set publish=false to crates that are not meant to be published on crates.io
Mysteriously, depending on toml_edit gives strange (reproducible) cargo
doc test errors due to "changed" dependencies. There must be some
"cross" dependency between this and the run-time library perhaps that
ends up with a recompilation somewhere. Switch to cargo-toml2 just for
reading Cargo.toml -- unfortunately the fixing doesn't work as it
reformats the entire fail (and errors out). But since most files are
changed this might be okay for now.
By setting RUSTFLAGS in the Cargo config we run into the situation that
when doing a host build, all rust files are compiled with the flags,
including build.rs. When cross-compiling, build.rs is not build with the
RUSTFLAGS specified. That makes kind of sense, but it also means that
all the build scripts are always recompiled when switching between a
target and a host build - and that applies to *all* packages, including
dependencies.
So short of a better solution, this patch removes the need to set
RUSTFLAGS. It was used to extract the system library dependencies for
the static library we'd create. Instead we're now building two shared
libraries and are linking against them. They contain the rust library
twice, so that's not really a desirable final state either, but
productivity wins right now :-)
It might make sense to go back to creating *one* shared library through
a dedicated crate and -- since 'pub extern "C"' functions are not
transitively exported, it may require re-exporting them by hand or using
some clever build trick perhaps.
* 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.
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 :)
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.
