1 |
On 08/09/2016 12:58 AM, Fabian Groffen wrote: |
2 |
> On 08-08-2016 13:45:07 -0500, R0b0t1 wrote: |
3 |
>> On Mon, Aug 8, 2016 at 11:23 AM, Lei Zhang <zhanglei.april@×××××.com> wrote: |
4 |
>>> "cc" is the standard C compiler name defined in POSIX, so ideally any |
5 |
>>> gcc-agnostic programs should use "cc" instead of "gcc". Practically, |
6 |
>>> build tools like GNU Make and CMake would be affected as they use "cc" |
7 |
>>> implicitly. |
8 |
>> |
9 |
>> It is not just programs which rely on GNU extensions, but poorly |
10 |
>> created scripts that rely on a compiler directly or otherwise break |
11 |
>> portability. |
12 |
> |
13 |
> I'd agree and say "gcc" is hardcoded in many places, that's why I |
14 |
> believe Apple includes a gcc which is clang on their systems, same for |
15 |
> cc. |
16 |
> |
17 |
> As a question to Lei, I'm wondering why you chose eselect compiler, and |
18 |
> not gcc-config to manage the links. In a way, gcc-config is tailored |
19 |
> towards gcc, but it does a lot of things also for the environment. With |
20 |
> clang, from my experience, you just want it as drop-in replacement for |
21 |
> gcc as it doesn't give you too much issues (on Darwin at least). |
22 |
> |
23 |
> Fabian |
24 |
> |
25 |
> |
26 |
|
27 |
There are many things afoot with compilers, particularly related to |
28 |
distributed and tightly coupled parallel systems. Perhaps a name change |
29 |
from gcc-config to cc-config would be more accurate or better if that |
30 |
aspect of choice is to accurately reflect the choices going forward? |
31 |
|
32 |
Also, when you get down to smaller microprocessor levels there are often |
33 |
numerous choices for compilers. Granted, today, most of those are still |
34 |
commercial, but, pressure over time could very likely see many of those |
35 |
compilers going the open source route, confounding the choice issue for |
36 |
a more open naming convention for gcc-config? |
37 |
|
38 |
|
39 |
hth, |
40 |
James |