##// END OF EJS Templates
rhg: consistently use the command name given in clap::command!(<...>) macro...
rhg: consistently use the command name given in clap::command!(<...>) macro Before this patch there are 2 things the user controls: 1. the module/command name, specified in subcommand! macro 2. the command name, specified in clap::command! macro If these are out of sync, we get no compile error or a clear runtime error, but instead a confusing behavior where command line parser parses one thing, but running it doesn't work. This commit makes the clap::command! macro the sole authority determining the command name, so we don't have to worry about this weird behavior any more. It also makes it easy to validate agreement between (1) and (2) if we want it, but I didn't add the check because I'm not sure people necessarily want it.

File last commit:

r52561:45ba8416 stable
r53420:021c1b16 default
Show More
README.md
48 lines | 1.9 KiB | text/x-minidsrc | MarkdownLexer
Gregory Szorc
hgcli: customize for Mercurial...
r45129 # Oxidized Mercurial
This project provides a Rust implementation of the Mercurial (`hg`)
version control tool.
Under the hood, the project uses
[PyOxidizer](https://github.com/indygreg/PyOxidizer) to embed a Python
interpreter in a binary built with Rust. At run-time, the Rust `fn main()`
is called and Rust code handles initial process startup. An in-process
Python interpreter is started (if needed) to provide additional
functionality.
# Building
Kyle Lippincott
pyoxidizer: update README.md with several small fixes...
r49087 First, acquire and build a copy of PyOxidizer; you probably want to do this in
some directory outside of your clone of Mercurial:
Gregory Szorc
hgcli: customize for Mercurial...
r45129
$ git clone https://github.com/indygreg/PyOxidizer.git
$ cd PyOxidizer
$ cargo build --release
Kyle Lippincott
pyoxidizer: update README.md with several small fixes...
r49087 Then build this Rust project using the built `pyoxidizer` executable:
Gregory Szorc
hgcli: customize for Mercurial...
r45129
Kyle Lippincott
pyoxidizer: update README.md with several small fixes...
r49087 $ /path/to/pyoxidizer/target/release/pyoxidizer build --release
Gregory Szorc
hgcli: customize for Mercurial...
r45129
If all goes according to plan, there should be an assembled application
Kyle Lippincott
pyoxidizer: update README.md with several small fixes...
r49087 under `build/<arch>/release/app/` with an `hg` executable:
Gregory Szorc
hgcli: customize for Mercurial...
r45129
Kyle Lippincott
pyoxidizer: update README.md with several small fixes...
r49087 $ build/x86_64-unknown-linux-gnu/release/app/hg version
Gregory Szorc
hgcli: customize for Mercurial...
r45129 Mercurial Distributed SCM (version 5.3.1+433-f99cd77d53dc+20200331)
(see https://mercurial-scm.org for more information)
av6
copyright: update to 2024
r52561 Copyright (C) 2005-2024 Olivia Mackall and others
Gregory Szorc
hgcli: customize for Mercurial...
r45129 This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# Running Tests
To run tests with a built `hg` executable, you can use the `--with-hg`
argument to `run-tests.py`. But there's a wrinkle: many tests run custom
Python scripts that need to `import` modules provided by Mercurial. Since
these modules are embedded in the produced `hg` executable, a regular
Python interpreter can't access them! To work around this, set `PYTHONPATH`
to the Mercurial source directory. e.g.:
$ cd /path/to/hg/src/tests
Kyle Lippincott
pyoxidizer: update README.md with several small fixes...
r49087 $ PYTHONPATH=`pwd`/.. python3.9 run-tests.py \
--with-hg `pwd`/../rust/hgcli/build/x86_64-unknown-linux-gnu/release/app/hg