Date: Fri, 16 Jan 2009 11:56:34 +0100 From: Christoph Mallon <christoph.mallon@gmx.de> To: "Svein Skogen (listmail account)" <svein-listmail@stillbilde.net> Cc: freebsd-current@freebsd.org, Sabeeh Baig <baigsabeeh@gmail.com> Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) Message-ID: <497067E2.2000806@gmx.de> In-Reply-To: <49706341.8060207@stillbilde.net> References: <de2964020901141507m5a30c466ta1e05694d220ce0b@mail.gmail.com> <20090115084515.GA91157@freebsd.org> <496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com> <49706341.8060207@stillbilde.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Svein Skogen (listmail account) schrieb: > Garrett Cooper wrote: >> On Thu, Jan 15, 2009 at 2:59 PM, Maxim Sobolev <sobomax@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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497067E2.2000806>