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