upstream/mercurial-mirror Files · rust/hgcli/README.rst

phabricator: use .arcconfig for the callsign if not set locally (issue6243)...

phabricator: use .arcconfig for the callsign if not set locally (issue6243) This makes things easier for people working with more than one repository because this file can be committed to each repository. The bug report asks to read <repo>/.arcrc, but AFAICT, that file lives in ~/ and holds the credentials. And we already track an .arcconfig file. Any callsign set globally is still used if that is all that is present, but .arcconfig will override it if available. The idea behind letting the local hgrc override .arcconfig is that the developer may need to do testing against another server, and not dirty the working directory. Originally I was going to just try to read the callsign in `getrepophid()` if it wasn't present in the hg config. That works fine, but I think it also makes sense to read the URL from this file too. That would have worked less well because `readurltoken()` doesn't have access to the repo object to know where to find the file. Supplimenting the config mechanism is less magical because it reports the source and value of the properties used, and it doesn't need to read the file twice. Invalid hgrc files generally cause the program to abort. I only flagged it as a warning here because it's not our config file, not crucial to the whole program operating, and really shouldn't be corrupt in the typical case where it is checked into the repo. Differential Revision: https://phab.mercurial-scm.org/D7934

Valentin Gatien-Baron - - Load All Authors

File last commit:

r44573:8a3b045d default


                r44586:59b3fe1e

default

Download file

             README.rst
        
                    58 lines
            
             | 1.8 KiB
            
                | text/x-rst
            
             |
                RstLexer
            
             / rust / hgcli / README.rst
          
                    History
                
                 |
                  Source
                 | Raw
                 |Copy content
                 |Copy permalink

        Valentin Gatien-Baron
    
rust: move hgcli's README out of the way...

              r44573
            
      Features

      --------

      The following Cargo features are available:

      localdev (default)

         Produce files that work with an in-source-tree build.

         In this mode, the build finds and uses a ``python2.7`` binary from

         ``PATH``. The ``hg`` binary assumes it runs from ``rust/target/<target>hg``

         and it finds Mercurial files at ``dirname($0)/../../../``.

      Build Mechanism

      ---------------

      The produced ``hg`` binary is *bound* to a CPython installation. The

      binary links against and loads a CPython library that is discovered

      at build time (by a ``build.rs`` Cargo build script). The Python

      standard library defined by this CPython installation is also used.

      Finding the appropriate CPython installation to use is done by

      the ``python27-sys`` crate's ``build.rs``. Its search order is::

      1. ``PYTHON_SYS_EXECUTABLE`` environment variable.

      2. ``python`` executable on ``PATH``

      3. ``python2`` executable on ``PATH``

      4. ``python2.7`` executable on ``PATH``

      Additional verification of the found Python will be performed by our

      ``build.rs`` to ensure it meets Mercurial's requirements.

      Details about the build-time configured Python are built into the

      produced ``hg`` binary. This means that a built ``hg`` binary is only

      suitable for a specific, well-defined role. These roles are controlled

      by Cargo features (see above).

      Running

      =======

      The ``hgcli`` crate produces an ``hg`` binary. You can run this binary

      via ``cargo run``::

         $ cargo run --manifest-path hgcli/Cargo.toml

      Or directly::

         $ target/debug/hg

         $ target/release/hg

      You can also run the test harness with this binary::

         $ ./run-tests.py --with-hg ../rust/target/debug/hg

      .. note::

         Integration with the test harness is still preliminary. Remember to

         ``cargo build`` after changes because the test harness doesn't yet

         automatically build Rust code.

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

Valentin Gatien-Baron rust: move hgcli's README out of the way...	r44573	Features
		--------

		The following Cargo features are available:

		localdev (default)
		Produce files that work with an in-source-tree build.

		In this mode, the build finds and uses a ``python2.7`` binary from
		``PATH``. The ``hg`` binary assumes it runs from ``rust/target/<target>hg``
		and it finds Mercurial files at ``dirname($0)/../../../``.

		Build Mechanism
		---------------

		The produced ``hg`` binary is bound to a CPython installation. The
		binary links against and loads a CPython library that is discovered
		at build time (by a ``build.rs`` Cargo build script). The Python
		standard library defined by this CPython installation is also used.

		Finding the appropriate CPython installation to use is done by
		the ``python27-sys`` crate's ``build.rs``. Its search order is::

		1. ``PYTHON_SYS_EXECUTABLE`` environment variable.
		2. ``python`` executable on ``PATH``
		3. ``python2`` executable on ``PATH``
		4. ``python2.7`` executable on ``PATH``

		Additional verification of the found Python will be performed by our
		``build.rs`` to ensure it meets Mercurial's requirements.

		Details about the build-time configured Python are built into the
		produced ``hg`` binary. This means that a built ``hg`` binary is only
		suitable for a specific, well-defined role. These roles are controlled
		by Cargo features (see above).

		Running
		=======

		The ``hgcli`` crate produces an ``hg`` binary. You can run this binary
		via ``cargo run``::

		$ cargo run --manifest-path hgcli/Cargo.toml

		Or directly::

		$ target/debug/hg
		$ target/release/hg

		You can also run the test harness with this binary::

		$ ./run-tests.py --with-hg ../rust/target/debug/hg

		.. note::

		Integration with the test harness is still preliminary. Remember to
		``cargo build`` after changes because the test harness doesn't yet
		automatically build Rust code.