[PATCH] D71786: RFC: [Support] On Windows, add optional support for rpmalloc

Wed Jul 1 08:06:02 PDT 2020

Meinersbur added a comment.

In D71786#2124872 <https://reviews.llvm.org/D71786#2124872>, @hans wrote:

> I also don't know what exactly the policy around third_party code is, so discussing this on llvm-dev is probably a good idea.
>
> But perhaps one way of side-stepping the whole issue would be to not check in rpmalloc into LLVM, but make the user point at it if they want to use it through a cmake variable, e.g. -DLLVM_USE_RPMALLOC=c:\path\to\rpmalloc (if such a thing is technically practical, I don't know)

That diverges from what we have done in other cases (ConvertUTF, gtest, gmock, google benchmark, isl, ...), adds to the effort to build LLVM and adds a dimension to the cmake configuration space.

================
Comment at: llvm/lib/Support/rpmalloc/LICENSE:24
+
+For more information, please refer to <http://unlicense.org>
----------------
russell.gallop wrote:
> rnk wrote:
> > My understanding is that lawyers do not like one-off licenses. However, I think there is a pretty clear case that rpmalloc is not critical functionality to LLVM, it is an implementation of a well-defined interface: malloc, and if we discover license complications down the road, we can always remove it without removing critical functionality. And if anyone finds this worrying today, they do not need to enable the rpmalloc build mode.
> > 
> > So, that is my non-authoritative, "not legal advice" rationalization that this should be OK. And, you did put all the code in the rpmalloc directory. So, I think this is fine.
> I believe that rpmalloc can be licensed under the MIT license if the lawyers would be happier with this: https://github.com/mjansson/rpmalloc#license
Taking the occasion to point to another licence issue we already have: D66390

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71786/new/

https://reviews.llvm.org/D71786