##// END OF EJS Templates
packaging: isolate invocation of WiX to own function...
packaging: isolate invocation of WiX to own function Like we did for Inno, we want to split out the building of Mercurial from invoking the packaging tool so that we can introduce an alternate build mechanism. As part of this refactor, there are inconsequential changes to file layouts. Before, some shared files such as the WiX binaries and merge modules would be installed under build/. Now, they are installed under build/wix-*. This is to keep implementation simpler. But it also helps keep build state more isolated. Differential Revision: https://phab.mercurial-scm.org/D8474

File last commit:

r44786:d8d4fa9a default
r45257:11bd68a9 default
Show More
mod.rs
21 lines | 1.0 KiB | application/rls-services+xml | RustLexer
/// re2 module
///
/// The Python implementation of Mercurial uses the Re2 regex engine when
/// possible and if the bindings are installed, falling back to Python's `re`
/// in case of unsupported syntax (Re2 is a non-backtracking engine).
///
/// Using it from Rust is not ideal. We need C++ bindings, a C++ compiler,
/// Re2 needs to be installed... why not just use the `regex` crate?
///
/// Using Re2 from the Rust implementation guarantees backwards compatibility.
/// We know it will work out of the box without needing to figure out the
/// subtle differences in syntax. For example, `regex` currently does not
/// support empty alternations (regex like `a||b`) which happens more often
/// than we might think. Old benchmarks also showed worse performance from
/// regex than with Re2, but the methodology and results were lost, so take
/// this with a grain of salt.
///
/// The idea is to use Re2 for now as a temporary phase and then investigate
/// how much work would be needed to use `regex`.
mod re2;
pub use re2::Re2;