Lots of work today - #94
Merged
Merged
Conversation
It seems that in Rust 1.18 (and current 1.19 nightly for what that's worth), the order in which dependent OS libraries are emitted by build.rs matters more than it used to. Strangely, regular builds would work fine, but the build of `tectonic.rlib` for `cargo test` would get a link error because our `libtectonic_cpp.a` needed a link to `libz`, but the relevant `-lz` flag was only placed in the command line *before* the command to link in `libtectonic_cpp.a`, which of course doesn't get the job done in the order-dependent way that `ld` works. So, we need to emit the relevant `-lz` flags *after* linking in our own libraries; but we can't get the correct C include paths for our libraries without doing the pkg-config call, which is what emits the Cargo metadata for the OS library links. The solution is simple: just run pkg-config twice. The `pkg_config` crate has an option to not print the cargo metadata so we can even suppress its emission on the first invocation, although I don't think it would be a problem to print everything twice. It would be nice if the `pkg_config::Library` object had a method to print the relevant metadata so that we didn't have to invoke pkg-config twice. But, really, who cares?
Look at this diff in whitespace-hiding mode since that's all that's actually changed.
They're kind of hairy and we have an instance where the separate "for_end" variable used by WEB2C looks as if it could/should be relevant.
Including some comments about what's going on with all the "sup" processing.
For testing, it is handy to be able to compare errors and results, but Rust error types don't generically implement PartialEq. Hack around this with our own DefinitelySame trait that lets us get the right effect, where false is returned for two objects that we don't *know* to be equal. In so doing I think I've run into an issue with Rust's trait coherence. I want to implement DefinitelySame for anything that's PartialEq, but if I do so Rust thinks that the impl conflicts with the one for std::Result, even though std::Result is only PartialEq if its subtypes are PartialEq, as I understand it. For now we just hack around it.
The "coda tokens" are inserted if processing makes it to the very end of the
initial input without seeing a \end or \dump. (Note that \everyeof has
different semantics.) This can be used to avoid boilerplate like LaTeX's
`\end{document}` with an appropriately-tuned format file.
The "primary input" is (as of this commit) the initial stream that the TeX engine starts parsing. To date, the engine was given a file name to parse, and it tried to open that file using the I/O subsystem and went from there. This was dissatisfying for two reasons. First, it meant that if you wanted to synthesize a primary input for the TeX engine (e.g., stdin or a text string in memory), you had to make up a "filename" for it and wire that in to the I/O system. This felt fragile and inelegant. Second, even if the primary input file was a genuine file on disk, we had to make sure that it would parse properly if it contained special characters -- the previous code expanded tokens as it parsed the filename so all sorts of crazy things could happen. And, although this is definitely an edge case, we wouldn't be able to handle non-Unicode Unix filenames. This system adds a new I/O API requesting to open the primary input stream in particular -- a mirror of `output_open_stdout`, in a certain sense. The Rust/C bridge has then been updated to allow the Rust code to start up I/O on the primary input using this API and circumventing the standard file-opening shenanigans, which basically pretend that the user has just typed "\input $1". As an example of how this makes life better, I'll soon add better support for TeX processing of a document delivered on stdin. I also believe that this infrastructure will improve our ability to handle relative paths in documents.
If you specify "-" as the input filename, the CLI will buffer standard input and process it, including looping through it multiple times if needed. The outputs will be named "texput" and land in the current directory. The previous commit was quite complicated, but this one isn't so bad, is it?
The biggest problem was that xdvipdfmx is pretty good about all of its byte types being unsigned chars, while the XeTeX code assumed the opposite, so there was no obvious approach that made both pieces of code happy without some sign casting in the Tectonic I/O function calls. There were also some other problems in here, including signed/unsigned swaps in the image loaders that could potentially have been genuinely problematic.
Now that the way that we pass the input file's path to TeX has been straightened out a bit, we can have the CLI be smarter about input paths. First of all, we adopt the discussed schema that the filesystem location of the main input file is treated as a virtual "CWD". If you're processing "foo/bar.tex" and it does "\input other.tex", we will attempt to open the file "foo/other.tex". Second, we are more careful about the paths that we send to tex. In the example above it gets told that the input file name is "bar.tex", and if there is any Unicode zaniness it gets ironed out. *That* path is what TeX uses to determine the names of the output files it creates, so in the CLI we adapt them appropriately. Finally, when writing output files we now also anchor them to the input. So in the above example, the final output will be "foo/bar.pdf". I think it all works. Closes tectonic-typesetting#31.
Contributor
|
This PR makes the tests fail on my machine: |
Collaborator
Author
|
Remove |
Contributor
|
It works, thanks :) |
Mrmaxmeier
pushed a commit
to Mrmaxmeier/tectonic
that referenced
this pull request
Oct 1, 2019
…tra-match-in-bibtex Remove extra match in engine/src/bibtex.rs
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Getting input name handling, input from stdin, relative paths, and more.