Chromium can be built using clang, but it requires more setting up than a simple export of CC and CXX (see https://code.google.com/p/chromium/wiki/Clang ). I suggest to add an llvm (since it's used in a similar way in mesa) (alternatively, use add the clang flag? ) USE flag to chromium to allow those who wish to compile it using it. I tested to make sure that chromium fails to compile (build log included). The error that fails the build is that the copying parameter of type WebCore::MediaQueryEvaluator invokes a deleted constructor. My emerge --info is here: https://gist.github.com/9221238 To build chromium with clang I use the basic environment file (flaggie chromium +clang), in which I export CC=clang and CXX=clang++
What we could possibly do is add a new category (ala PYTHON_TARGETS PYTHON_SINGLE_TARGET). Something along the lines of: COMPILERS="gcc clang" (defined in profile per-system, so gentoo/alt will be happy too) then TARGET_COMPILER="clang" (has to be exactly one of COMPILERS) then whatever fails with compiler X you can simply override it to target_compiler_gcc use flag, for example.
With chromium-33.0.1750.117 I'm getting a different error (34 is the same as 35): ../../third_party/WebKit/Source/core/inspector/InspectorPageAgent.cpp:1212:50: error: copying parameter of type 'WebCore::MediaQueryEvaluator' invokes deleted constructor ruleSet->addRulesFromSheet(styleSheet.get(), MediaQueryEvaluator("screen")); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../third_party/WebKit/Source/core/css/MediaQueryEvaluator.h:55:26: note: function has been explicitly marked deleted here WTF_MAKE_NONCOPYABLE(MediaQueryEvaluator); WTF_MAKE_FAST_ALLOCATED; ^ ../../third_party/WebKit/Source/wtf/Noncopyable.h:29:13: note: expanded from macro 'WTF_MAKE_NONCOPYABLE' ClassName(const ClassName&) = delete; \ ^ 150 warnings and 1 error generated. And again, IMHO the code should just compile with no explicit setting like "compile for gcc" or "compile for clang" or "override the compiler to be gcc even though the user asked for clang". We're going to address the compile issue and respect the user's choice.
Making this work automatically in the upstream build system is certainly a good goal. However, until that happens, it makes sense deal with it in the ebuild rather than ignoring the problem until the ideal solution is committed upstream. I'm not saying that you should spend much time on it, but if a user submits a reasonable patch I don't think we should reject it on the basis that it isn't automagic enough.
Any way I can help the development upstream? I'd be actually interested. (btw I'm currently moving most of my system over to clang as said in Description, and I have a semi-automated system to do so now, I'll submit it later)
To be able to compile chromium with llvm it would be great for my poor AMD E-350: * www-client/chromium Sat Mar 1 16:56:33 2014 >>> www-client/chromium-34.0.1847.14 merge time: 6 hours, 2 minutes and 16 seconds. Firefox, Thunderbird and Libreoffice compile times were reduced with ~33% when I switched to clang. I do not like binary versions, either google chrome, despite that installing them would be less time consumming. I'll try to compile ebuild chromium phase and export vars to be able to use llvm. I'll report back.
Exporting GYP_DEFINES=clang=1 during phases it's not enought. Silly assumption :)
(In reply to Mike Gilbert from comment #4) > Making this work automatically in the upstream build system is certainly a > good goal. > > However, until that happens, it makes sense deal with it in the ebuild > rather than ignoring the problem until the ideal solution is committed > upstream. > > I'm not saying that you should spend much time on it, but if a user submits > a reasonable patch I don't think we should reject it on the basis that it > isn't automagic enough. Agreed. Feel free to apply such a patch, I can also do that when someone posts it.
I can confirm that it works, also. Thank you!
Also confirming, was getting a fail on 41, but 42+ seems ok for building with clang!
42 is now stable, closing.
[Redacting #1 to remove PII] (In reply to Paweł Hajdan, Jr. (RETIRED) from comment #1) > (In reply to [redacted] from comment #0) > > I tested to make sure that chromium fails to compile (build log included). > > The error that fails the build is that the copying parameter of type > > WebCore::MediaQueryEvaluator invokes a deleted constructor. > > I don't see any build log attached (you may need to xz-compress it to fit > within the attachment limit). > > Here's what I get with chromium-35.0.1862.2 and clang-3.4-r100: > > ../../net/disk_cache/v3/entry_impl_v3.cc:1394:61: error: cannot pass object > of non-POD type 'disk_cache::Addr' through variadic function; call will > abort at runtime [-Wnon-pod-varargs] > Trace("%s 0x%p 0x%x", msg, reinterpret_cast<void*>(this), address_); > ^ > 68 warnings and 1 error generated. > > Note that I'd like to avoid having explicit USE flags for building with > clang, see e.g. bug #422829 .
[Redacting two more] (In reply to Paweł Hajdan, Jr. (RETIRED) from comment #9) > 19 Feb 2015; Pawel Hajdan jr > chromium-42.0.2305.3.ebuild: > Fix build with clang, bug #502456 by [redacted] > > Example usage: CC=clang CXX=clang++ BUILD_CC=clang BUILD_CXX=clang++ emerge > -1av chromium > > I plan to keep the bug open until the fix gets to stable. > > Please test and confirm whether it works for you. (In reply to Petr Vaněk from comment #10) > (In reply to Paweł Hajdan, Jr. from comment #9) > > 19 Feb 2015; Pawel Hajdan jr > > chromium-42.0.2305.3.ebuild: > > Fix build with clang, bug #502456 by [redacted] > > > > Example usage: CC=clang CXX=clang++ BUILD_CC=clang BUILD_CXX=clang++ emerge > > -1av chromium > > > > I plan to keep the bug open until the fix gets to stable. > > > > Please test and confirm whether it works for you. > > It works for me.
