[Fedr]

In MeshLib's own builds, BitSet now stores its blocks with mimalloc explicitly: BitSet::Blocks = std::vector<block_type, Allocator<block_type>>, where the new MRAllocator.h defines MR::Allocator<T> as mi_stl_allocator<T>, or std::allocator<T> with Emscripten and MR_MIMALLOC_OVERRIDE, and MeshLib's executables no longer override malloc. Applications that override malloc, such as MeshInspector, set MR_MIMALLOC_OVERRIDE=ON and build exactly as on master. The dependency trees (CPM, vcpkg, Homebrew) are unchanged.

MeshLib builds (MR_MIMALLOC_OVERRIDE=OFF, default)

• MRMesh links mimalloc PUBLIC through mr_find_mimalloc().
  • Windows: vcpkg's mimalloc.dll, as before. Its redirect engages only in executables set up by mr_enable_mimalloc / MimallocRedirect.props, and MRTest and MeshViewer no longer are.
  • macOS and Linux: the dependencies' mimalloc overrides malloc, and a plain Python that loads it late segfaults (Linux) or crashes (macOS). So MeshLib builds its own non-override copy of the same pinned version (3.5.3), named MRMimalloc so it cannot collide with the dependencies' libmimalloc. It is installed next to the MeshLib libraries, and on Linux it uses dlopen-safe thread-locals.
• MRMeshConfig.cmake defines the mimalloc target for code built against installed MeshLib: MRMimalloc next to MRMesh, or vcpkg's package on Windows. On MSVC, MRAllocator.h auto-links mimalloc(-debug).dll.lib, so consumers that link only MRMesh by name (the C++ examples, distribution users) resolve the inline mi_free.
• MRTest and MeshViewer keep the system allocator. MRMimallocRedirectTests.cpp checks that BitSet blocks, including ones allocated inside MRMesh, come from mimalloc and that malloc does not. On Linux it also checks that the process has a single mimalloc.
• Emscripten keeps std::allocator: with MR_EMSCRIPTEN_MIMALLOC malloc is already mimalloc, and the C-bindings image (emsdk 3.1.38) has no mimalloc at all.
• bits() and fromBlocks are hidden from the bindings (MR_BIND_IGNORE), because mrbind drops custom allocators. No binding test or example used them. generate.mk reads MR_MIMALLOC_OVERRIDE from MRMesh's config_cmake.h, so the bindings agree with MRMesh on BitSet::Blocks.
• MRCuda builds its result blocks as BitSet::Blocks, and DynamicArray accepts a std::vector with any allocator.

Applications (MR_MIMALLOC_OVERRIDE=ON)

Everything is as on master. BitSet uses std::allocator, MeshLib libraries do not link mimalloc, and MRTest, MeshViewer and the application's mr_enable_mimalloc executables override malloc with the dependencies' mimalloc. mr_enable_mimalloc fails at configure time on macOS and Linux without the option. MeshInspector turns it on in a companion PR.

🤖 Generated with Claude Code