mirror of
https://github.com/facebook/sapling.git
synced 2024-10-12 09:48:05 +03:00
90e4ab0d4e
Summary:
After D15266191, the bindings crate directly depends on pyrevisionstore, and
since then we have seen really weird compilation errors that magically go away
when some files are touched.
From my observations, here is what I came up with. The pyrevisionstore crate is
both compiled as a dependency of the bindings crate, and as a library to be
used in python. Therefore, its Cargo.toml contains a '[lib]' section, the
presence of this section forces the crate to be compiled into a
"libpyrevisionstore.{rlib,so}", while all the regular crates have a hashed
suffix like "libedenapi-2b9975ec9b865e87.rlib".
None of this would usually matter, but our build system re-uses the build
directory to then compile the pyrevisionstore library. While doing so, it will
re-create the "libpyrevisionstore.{rlib,so}", but not in an identical fashion.
After this, the rest of the build succeeds.
Once a file in the bindings crate is touched, recompiling will only recompile
its file, and not the pyrevisionstore crate, but since
"libpyrevisionstore.{rlib,so}" is different, it now fails to compile...
A previous effort tried to compile each top level target into a separate
directory, but that directly affected some of our tests. Since the underlying
issue is that pyrevisionstore is compiled twice, let's simply not compile it as
a top-level target and simply fold it into the bindings lib. Ideally, we would
want to do the opposite, but let's do that at a later time.
Reviewed By: DurhamG
Differential Revision: D15381038
fbshipit-source-id: 047cfab794371464942f19084ffb9240e836cb40
|
||
|---|---|---|
| .. | ||
| cfastmanifest | ||
| cstore | ||
| ctreemanifest | ||
| indexes | ||
| phabricator | ||
| pyrevisionstore | ||
| pywatchman | ||
| watchmanclient | ||
| __init__.py | ||
| Cargo.toml | ||
| cfastmanifest.c | ||
| linelog.pyx | ||
| litemmap.pyx | ||
| mysqlutil.py | ||
| README.md | ||
| traceprofimpl.cpp | ||
extlib
Code that extensions depend on, but aren't themselves extensions, should go here. Both native (C/C++/Cython/Rust) and Python code is allowed. Code that depends on Python is also allowed.
In theory, this code should slowly disappear as extension code gets folded into
mainline Mercurial. (The native bits should go into lib/ or mercurial/cext),
the Python code into mercurial/ itself.)
See also lib/README.md, mercurial/cext/README.md.