| 1 |
On Wed, 10 Aug 2016 01:52:29 +0100 |
| 2 |
"M. J. Everitt" <m.j.everitt@×××.org> wrote: |
| 3 |
|
| 4 |
> On 10/08/16 01:39, Lei Zhang wrote: |
| 5 |
> > 2016-08-09 13:58 GMT+08:00 Fabian Groffen <grobian@g.o>: |
| 6 |
> >> As a question to Lei, I'm wondering why you chose eselect compiler, and |
| 7 |
> >> not gcc-config to manage the links. In a way, gcc-config is tailored |
| 8 |
> >> towards gcc, but it does a lot of things also for the environment. With |
| 9 |
> >> clang, from my experience, you just want it as drop-in replacement for |
| 10 |
> >> gcc as it doesn't give you too much issues (on Darwin at least). |
| 11 |
> > In its current form, gcc-config specializes in handling different |
| 12 |
> > versions of gcc. If we extend it to cover other compilers (and rename |
| 13 |
> > it to cc-config as James suggested), should it handle different |
| 14 |
> > versions of clang? What about different versions of icc? |
| 15 |
> > |
| 16 |
> > I'm just afraid gcc-config would become too complex that way, so I |
| 17 |
> > prefer a simpler approach: let eselect-compiler be version-agnostic. |
| 18 |
> > Then we can have clang-config to handle the versioning of clang, |
| 19 |
> > icc-config to handle icc, etc. |
| 20 |
> > |
| 21 |
> > |
| 22 |
> > Lei |
| 23 |
> > |
| 24 |
> Extending the ideas presented in this thread .. you could introduce |
| 25 |
> cc-config, and which utility script it runs would then be governed by |
| 26 |
> eselect compiler .. eg. gcc would have gcc-config, clang would run |
| 27 |
> clang-config .. |
| 28 |
|
| 29 |
.. to switch between the one version of clang that can be installed? |
| 30 |
|
| 31 |
-- |
| 32 |
Best regards, |
| 33 |
Michał Górny |
| 34 |
<http://dev.gentoo.org/~mgorny/> |
Archives