It turns out that in order to get the C/C++ crate-bridging to work
reliably with headers, we can't get away with exposing just a single
include directory from one crate to another; we have to expose a list of
include directories. So, change all of the relevant cases to be
semicolon-separated lists instead of single directory names. Not my
favorite but I don't see a way around it.
Last in the current push. Now that we have bridges for all of these
system libraries, we can start pushing backwards and making it possible
to vendor them.
I was hoping to use `rust_icu_sys` here, since it prints out a Cargo
line that we can use to find its C headers, but the currently released
version requires nightly, has a build bug on my machine, and would add
`bindgen` as a build-time dependency.
Instead of having the C code depend directly on zlib, expose the zlib
functionality through a cbindgen API provided by this new crate, which
links to flate2. By setting the `links` field in Cargo.toml, we can
expose a C include path that can be used by the `tectonic` build.rs
script.
This doesn't actually simplify life right now, but it starts setting us
up to have more control over our C library dependencies. We can't change
anything yet because other C library dependencies link to zlib, so we
can't vendor it without causing symbol clashes, but we set up for
migration in the future as the higher-level dependencies are adapted.
There is a lot going on here so I hope that I got it all right. There is
new code relating to CMaps that alters the PDF output, so unfortunately
it does not seem practical to try to make it so that the new code can
pass the existing PDF-output test suite.
By "semi-static" I mean that the final binary is not statically linked, but
that it only dynamically links with core system libraries. Higher-level like
harfbuzz are linked into the executable statically. This is accomplished by an
environment variable TECTONIC_PKGCONFIG_FORCE_SEMI_STATIC=1, since I
discovered that the pkg-config-rs library's logic for encouraging static
linking will turn it off in the common case that our static libraries live in
standard system prefixes.
Unfortunately, graphite2 seems to have issues with its various static builds
(e.g. https://github.com/silnrsi/graphite/pull/54) so we won't always get a
super-minimal list of dependencies, but this seems to get us most of the way
there, and I've coded it so that we should start doing better if/when
graphite2 is fixed.
I got a little obsessed with the challenge of developing a macro that could
support fully general `cfg!` syntax. I came up with something, but the
solution involves basically restructuring the entire module. In the end,
though, we have a single static initialization of the environment variables
and don't need to build complex structures representing each test, so it feels
like a nice solution.
Final file names are along the lines of "xetex-XeTeXFontMgr.h" Note that the
classes that these files define have names such as `XeTeXFontMgr`, so it seems
best to keep the "XeTeX" in the filename.
At first I wasn't sure whether to fold these files into the `xetex-` prefix or
not, but they really do form an isolated subsystem. There was also some
confusion because there are essentially two Engine.h files -- one pure C, one
C++.
CraftSpider