Summary: | sys-devel/gcc-config: support changing target of cc, cpp, & c++ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dmitri Seletski <drjoms> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED OBSOLETE | ||
Severity: | enhancement | CC: | binki, mgorny, voyageur |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 26757 |
Description
Dmitri Seletski
2010-08-04 17:15:25 UTC
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. |