sapling/lib
Kostia Balytskyi 0ef59877cd hg: some portability fixes to py-cdatapack.h
Summary:
1. Variable Length Arrays are not supported by MSVC, but since this is a C++ code, we can just use heap allocation
2. Replacing `inet` with portability version

Depends on D7196403

Reviewed By: quark-zju

Differential Revision: D7196605

fbshipit-source-id: a0d88b6e06f255ef648c0b35a99b42ba3bee538a
2018-04-13 21:51:24 -07:00
..
cdatapack hg: some portability fixes to py-cdatapack.h 2018-04-13 21:51:24 -07:00
clib hg: start using imported mman-win32 in the portability headers 2018-04-13 21:51:10 -07:00
linelog hg: basic support for building hg using buck 2018-04-13 21:50:58 -07:00
radixbuf radixbuf: avoid using unstable features in buck build 2018-04-13 21:51:12 -07:00
third-party fixing xdiff build on windows 2018-04-13 21:51:23 -07:00
vlqencoding vlqencoding: add read_vlq_at API that works for AsRef<[u8]> 2018-04-13 21:51:19 -07:00
README.md READMEs: tweaks based on feedback 2018-01-12 12:35:52 -08:00

lib

Any native code (C/C++/Rust) that Mercurial (either core or extensions) depends on should go here. Python code, or native code that depends on Python code (e.g. #include <Python.h> or use cpython) is disallowed.

As we start to convert more of Mercurial into Rust, and write new paths entrirely in native code, we'll want to limit our dependency on Python, which is why this barrier exists.

See also hgext/extlib/README.md, mercurial/cext/README.mb.

How do I choose between lib and extlib (and cext)?

If your code is native and doesn't depend on Python (awesome!), it goes here.

Otherwise, put it in hgext/extlib (if it's only used by extensions) or mercurial/cext (if it's used by extensions or core).