Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?)

Garrett Cooper wrote:
> On Thu, Jan 15, 2009 at 2:59 PM, Maxim Sobolev <sobomax_at_freebsd.org> wrote:
>> Roman Divacky wrote:
>>> On Wed, Jan 14, 2009 at 06:07:48PM -0500, Sabeeh Baig wrote:
>>>> There is work being done on PCC, which is already capable of compiling
>>>> the OpenBSD and NetBSD userlands.  PCC is also quite a bit smaller and
>>>> already performs better than GCC.  OpenBSD folks are helping with the
>>>> development of PCC, so they can replace GCC in the base.  That might
>>>> be a solution for FreeBSD too, at least as a system compiler.  GCC
>>>> could be available as an add-on through ports for those who need it.
>>> I really dont see any reason why there must be only ONE compiler that
>>> can be used to compile FreeBSD.
>>>
>>> If you will work on making FreeBSD compile with pcc I am sure noone
>>> will mind. I am working on clang..... someone else might pick cparser
>>> and god knows what else....
>> Nice idea, but...
>>
>> I think that one thing that people often forget about when talking about
>> using external compiler to build base system is that FreeBSD is not only
>> self-hosted, but also that it supports cross-builds of any of the supported
>> arches. This feature would be physically impossible to maintain for any
>> extended period of time with 10 supported compilers maintained outside of
>> the tree.
>>
>> -Maxim
> 
> My thoughts:
> - Although choice is a good thing, I believe that unless you are ready
> and willing to accept the pains of maintaining multiple toolchains,
> that there needs to be a small set of acceptable status quo compilers
> that we work with, otherwise we will end up with a maintenance mess in
> the end. Take Gentoo Linux: it's a Linux distribution riddled with
> choices -- so many bloody choices that one has to make to get a
> working system, that just one library going south with the wrong
> option can set you back hours or days in order to get up and going
> again... we shouldn't go down that road or we'll just be begging for
> pain, if not from a support end, then from a user endpoint because
> we'll be more efficient manufacturers of rope than ever before, and
> users will be isolated from folks trying to reproduce their issues.
> - Like it or not, gcc is the defacto standard, just because it has
> been around and has been tried and tested for so long. We need to
> stick with a more gcc-friendly compiler until people in the
> development community realize that there are other ANSI-C 89/99
> standard compilers out there than just what GNU releases.
> - I believe that our partners should in fact speak about which
> direction they prefer going in on this compiler issue as they're the
> ones ultimately holding the bag with the decision on what to do...
> Cheers,
> -Garrett

But... Couldn't this be done easier? For the main source tree, going
through each file and adding a commented header line with the
requirements should be manageable. Add to that a file such as
/usr/share/misc/c-compilers.info that holds a list of current available
compilers (compilers on the system), what features they have, and a
priority order. A minor parser running in the make buildworld could run
down the source codes dependancies on compiler functions, and then find
the highest priority compiler that has the required feature set,
possibly on a per folder basis, including checking for output platform
capability. The "trick" here is to agree on a standard header, and a
syntax for the compiler table, before starting out. But given that this
is an operating system that has a man page for the programming style, I
think there is a possibility of success.  ;)

A similar header could actually be used for ports as well, and wouldn't
really add more complexity than our current make/gmake solution.

//Svein