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

From: Christoph Mallon <christoph.mallon_at_gmx.de>
Date: Fri, 16 Jan 2009 11:56:34 +0100
Svein Skogen (listmail account) schrieb:
> 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.

What the hell? FreeBSD is an operating system not a test lab for 
compiler experiments!
Received on Fri Jan 16 2009 - 09:56:36 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:40 UTC