This is achieved with clap_complete.
The current v1 & v2 cli mixture makes it a bit difficult to offer
clean completions for the `tectonic` command, so for now we only
target the `nextonic` command exclusively for the v2 cli.
The motivation for this change is to fix the Windows pkg-config CI,
where MSYS2's switch to the `pkgconf` implementation of `pkg-config` has
surfaced challenges in this crate's build script. But, it is also true
that we only need harfbuzz-icu for versions of Harfbuzz that are very
old at this point, and separating out that dependency will help us work
towards potentially one day being able to swap out the ICU dependency
with something else. So it's good to make that jump for bigger reasons
than just the CI.
Some pending work surfaced a problem where the icudata link order wasn't
correct in some situations. Putting the link ordering hack with the rest
of the ICU logic fixes things.
This is basically a tactic to speed up the Windows builds. By default, vcpkg
builds both debug and release versions of requested libraries. There's probably
some good reason for that, but for us it just makes the builds a lot slower than
they need to be. We can avoid that by providing a custom "triplet" file that
disables the debug builds. In order to do this cleanly, we use new support from
cargo-vcpkg that adds support for an "overlay triplets" directory. Builds also
need to set the $VCPKGRS_TRIPLET environment variable so that vcpkg-rs can find
the packages it needs. We add some docs and a diagnostic warning if that may be
what's going on when a vcpkg fails to be found.
Attempting to work around something that I think is currently a Cargo
issue, reported here:
https://github.com/rust-lang/cargo/issues/10440
Basically, `cargo install tectonic` seems to fail because our
workspace-level `patch.crates-io` statement isn't propagated into the
sub-crate's Cargo artifact. I think I can work around this by adding an
individual patch statement, at the cost of getting a warning every time
I run Cargo.
This is a new engine for creating HTML from TeX. SPX is "semantically
paginated XDV", a slight variant on the XDV output created by the XeTeX
engine during TeX processing. It looks like the it will be a misnomer:
we're going to ignore the pagination of the XDV file. But whatever.
We add a dependency on a patched version of "pinot", a crate for
analyzing OpenType files. In order to deal with some math properly, we
need to parse some of the special OpenType math tables.
Also, update dependencies in Cargo.lock.
This crate supports introspection of the Tectonic/XeTeX TeX engine
internal data structures. It aims to support two major use cases:
1. Generating a C header with all of the magic constants needed for the
engine implementation.
2. Decoding "format files" so that one can understand *exactly* what's
going on in a given format.
The second functionality here isn't fully worked out, but a lot of the
pieces are in place.
It turns out that in some cases, biber needs access to various `.bib`
files that may be associated with the document build. Fortunately, the
`.run.xml` file contains exactly the information we need to populate the
temporary tool directly properly. We have to link in an XML parser, but
so be it.
I wasn't aware of the `.run.xml` file before and we potentially could
use it a lot more aggressively. We don't do that here, but the support
is written to try to be future-conscious.
Building off of the new core bridge API, we can provide a bit of a more
refined approach to security controls. `tectonic -X compile` and
`tectonic -X build` now take an `--untrusted` option that ensures that
`-Z shell-escape`, and any future insecure features, cannot be enabled.
As with the core bridge work, this changes the ProcessingSessionBuilder
to be in untrusted mode by default, and adds a new API to configure in a
more-trusted mode if that's what you want to do.
Start using the separated-out bundle implementation crate. Now you can
work with bundles, and the cache, without having to link to XeTeX and
everything! This is a BREAKING CHANGE because the original bundle
implementations have been removed, and the Bundle trait has gained a new
required method.
The app_dirs have been moved to a lower level. This is a subtle BREAKING
CHANGE because we remove the app_dirs error variant from our un-boxed
error type.
This extracts the "bundle" implementations into a standalone crate,
adding a bunch of documentation that has really clarified my thinking
about why we need to distinguish bundles from generic IoProviders
anyway. We also dramatically clean up the implementation of the caching
layer, drawing a cleaner separation between the caching mechanism and
the underlying "indexed tar" / "HTTP Range request" backend.
Fine, fix things up so that we build when the `serialization` Cargo
feature is disabled. This is getting annoying to support and I'm not
sure if it's useful anymore (we can build statically linked with proc
macros by adopting a cross-compilation model), but it wasn't too hard to
fix up here.
We have now split the handling of `Tectonic.toml` files into a separate
crate, `tectonic_docmodel`, so that other people can manipulate
documents without needing to link to the main crate and all of the extra
dependencies that it entails. This ends up working out pretty nicely, in
that we can maintain functionlity with a few targeted extension traits
that wire up the document settings to the actual engine invocations.
However! This is a BREAKING CHANGE because the `tectonic::document` and
`tectonic::workspace` modules have been removed. We don't need or want
them anymore! I doubt anyone has been using them, but if so, use
`tectonic_docmodel` instead, with the new extension traits in the
`tectonic::docmodel` module if needed.
rm-dr