[PATCH RFC] RFC: allow optional C++ 11 extensions with pybind11 for performance code

Laurent Charignon lcharignon at fb.com
Mon Feb 8 16:45:35 EST 2016



On 2/8/16, 1:33 PM, "Sean Farley" <sean at farley.io> wrote:

>
>Laurent Charignon <lcharignon at fb.com> writes:
>
>> # HG changeset patch
>> # User Laurent Charignon <lcharignon at fb.com>
>> # Date 1454965979 28800
>> #      Mon Feb 08 13:12:59 2016 -0800
>> # Branch stable
>> # Node ID 3c1ae9c7e93e8556fa7470919108a02bd989d040
>> # Parent  61f4d59e9a0be4e25c1aa016db1a80a540a9d337
>> RFC: allow optional C++ 11 extensions with pybind11 for performance code
>
>I am very much against this as I am also against writing code in rust /
>go / etc. Mercurial is a *system tool*. When cloning code on IBM
>BlueGene it is annoying as hell to have random dependencies sneak in
>like this. For reference, IBM BlueGene has had problem with codes that
>use C++.

I understand your concern but that is not the case, it is not a random
dependency.
Like our C extensions, the C++ extensions, would be *optional*.
If you are not able to compile them on some system, mercurial should still
work without them.

>
>C is much, much, much more portable. In fact, I would like to go even
>further and break out the C code we have into a shared library (for cffi
>sweetness).

It is true that C is more portable.
However, it is much more difficult (at least for me) to implement large
features like lazy manifest or tree manifest in C compared to rust / go /
C++.
How do you think we should proceed?
Do you suggest finding a C implementation of whatever
data-structure/feature that would work for us and include them in the
project?

Thanks,

Laurent



More information about the Mercurial-devel mailing list