Re: [gentoo-dev] [RFC] new eselect module: compiler

[Fabian Groffen]

On 10-08-2016 08:39:26 +0800, Lei Zhang wrote:
> 2016-08-09 13:58 GMT+08:00 Fabian Groffen <grobian@g.o>:
> > As a question to Lei, I'm wondering why you chose eselect compiler, and
> > not gcc-config to manage the links.  In a way, gcc-config is tailored
> > towards gcc, but it does a lot of things also for the environment.  With
> > clang, from my experience, you just want it as drop-in replacement for
> > gcc as it doesn't give you too much issues (on Darwin at least).
>
> In its current form, gcc-config specializes in handling different
> versions of gcc. If we extend it to cover other compilers (and rename
> it to cc-config as James suggested), should it handle different
> versions of clang? What about different versions of icc?
>
> I'm just afraid gcc-config would become too complex that way, so I
> prefer a simpler approach: let eselect-compiler be version-agnostic.
> Then we can have clang-config to handle the versioning of clang,
> icc-config to handle icc, etc.

Alright.  As Zac pointed out, my gcc-config idea was a bad one.  And it
wouldn't work very well with icc and many other compilers as well.

Reason I thought about it, is that I'd like to avoid setting
CC/CXX/OBJC/OBJCXX/BUILD_CC/BUILD_CXX and whatnot.  Currently,
toolchain-funcs' tc-getPROG does some magic to produce TRIPLET-PROG kind
of thing, and configure gets the triplet passed by Portage as well.  I
was hoping for it to find TRIPLET-clang at some point with all the
tooling in place without "hard-overriding" CC in make.conf.

Fabian


-- 
Fabian Groffen
Gentoo on a different level