In portage there is a file responsible for USE flags for certain packages. Since LLVM is getting popular, wouldn't it make sense to create something similar to previously mentioned file, but which instead of different compile options will actually compile with different compiler? I have seen performance boost of LLVM for Apache, on Phoronix, so, why not take advantage of this boost?(i am lame, I assume libs compiled with GCC will still work with LLVM) Reproducible: Always Steps to Reproduce: not a bug Expected Results: Certain packages may seriously benefit by means of speed from different compilers!
USE flags are not for controlling compilers if you want to use LLVM, then simply export the CC env var and friends to the compiler you want
But this is my point, there should be a separate file, lets call it, /etc/portage/package.cop(cop, for COmPiler). When ebuild is processed by portage just before compilation takes place it changes "CC", "CXX", "CPP" variables. Example: LLVM is known to produce superior binaries for Apache(I don't claim it, Phoronix benchmark, off their site does). Now, I change C/C++ compiler over variable, "happilly ever after"? I don't think so. Next time I do update for "world" and there is new version of Apache available - it uses GCC. Benefit boost gone... My point is, there should be a config file in portage system, which, let's say. for LLVM ebuilds, or even some other compiler. I put Apache into that file, and next time when I update "world" - Apache is compiled with LLVM, or whatever other compiler i may use. Shouldn't be very difficult, should it?
portage already supports per-package env settings in /etc/portage/
So I take it those variables allow for 'emerge -u world' with various compilers? If yes, I suppose this pretty much dead bug/improvement suggestion can be closed.
yes, per-package env settings are respected at all times. overriding `gcc` to actually run something else (like clang) is a bad idea. you could make an argument that perhaps cc, cpp, and c++ could be anything and so the user should be able to change them to gcc or clang. this wouldn't impact any packages (since those never use cc, cpp, or c++), just code you download/build. we can define a new config format that gcc-config will pick up. perhaps: /etc/env.d/gcc/alt/clang which will be a simple file like: CC=clang CXX=clang++ CPP=clang then gcc-config will have a parallel selection set so you can do: gcc-config --alt clang and then it'll symlink cc to clang, c++ to clang++, and cpp to clang.
I don't really think we need gcc-config to do anything here. We enforce CC and friends in ebuilds anyway, and for custom compiles you can specify the compiler yourself. Especially that autoconf will always pick gcc up anyway. As a side note: please do not abuse env.d. We're trying to get rid of directories that aren't used by env-update there.
Looks like the consensus here is that this should be achievable with package.env.
