[cfe-dev] Stand-alone clang builds vs gtest

Michał Górny via cfe-dev cfe-dev at lists.llvm.org
Sat Aug 27 02:37:06 PDT 2016

On Fri, 26 Aug 2016 15:49:01 +0200
Michał Górny via cfe-dev <cfe-dev at lists.llvm.org> wrote:

> Hello, everyone.
> I think this is my first posting to the LLVM mailing lists, so I'm
> going to shortly introduce myself. My name is Michał Górny;
> professionally I'm employed at PathScale, and in my free time I'm
> a Gentoo Linux developer. In the latter role, I'm the primary
> maintainer for LLVM packages in Gentoo and my main focus at the moment
> is bringing them up to the top quality of our packaging standards.
> In this, for a long time I had a goal of having fully stand-alone
> builds for all LLVM components -- that is, making it possible to build
> clang against installed LLVM (with no LLVM sources around), lldb
> against installed llvm+clang, etc. Recently the things seem to have
> improved a lot, and therefore I'd like to help finishing the task.
> From what I can see, clang's build is mostly stand-alone at the moment.
> The only thing that seems to be missing are unit tests, that are
> relying on gtest being provided from LLVM source tree. Without
> the source tree being available, the unit tests are disabled.
> I see a few possible ways of solving this, at least as far as Gentoo
> packaging is concerned, and I would like to ask which one would be
> the most preferred one. The ones I can think of are:
> 1. Making it possible to override LLVM_MAIN_SRC_DIR. Currently
> the directory is obtained from llvm-config, and since Gentoo builds are
> done in temporary directories specific to each package in question,
> the directory formerly recorded can't be used while building clang.
> An easy way out would be to unpack/checkout another copy of LLVM
> sources for use in clang, and pass that path to cmake. However,
> the disadvantage of this is that we'd end up unpacking quite a lot of
> files just for gtest.
> 2. Making it possible to provide gtest sources separately. Similar to
> the previous solution except that it is explicitly noted that we need
> only (upstream?) gtest sources. If we're to use upstream gtest sources,
> we'd have to copy cmake build files from LLVM. If we go this way, for
> consistency we should probably make it possible to use upstream gtest
> in LLVM itself as well.
> 3. Including gtest sources inside clang. This is probably the simplest
> solution, however it involves some more code duplication between
> multiple LLVM projects.
> 4. Installing gtest library in a dedicated directory. The LLVM build
> system used to install it top-level, and that was wrong. However, I
> guess we could live with providing it in a dedicated subdirectory where
> it would not collide with any other package.
> 5. Using system-wide gtest library install. We have a thing like that
> in Gentoo, with shared libraries; but I recall upstream calling that
> a bad idea, so I don't know if anyone would be interested in using it.

I did a little more research, and noticed LLVM ships quite modified
version of gtest, and therefore upstream options 2&5 are out. I'll
probably attempt implementing 4, and see how much effort it requires on
the side of clang/compiler-rt/etc.

Best regards,
Michał Górny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160827/ed0ca069/attachment.sig>

More information about the cfe-dev mailing list