[TESTING]: ClangBSD branch needs testing before the import to
kostikbel at gmail.com
Mon May 31 09:56:30 UTC 2010
On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote:
> On May 30, 2010, at 7:58 AM, Kostik Belousov wrote:
> > On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote:
> >> hi,
> >> ClangBSD was updated to LLVM/clang revision 104832 which is what we
> >> aim to import into HEAD in roughly a week. We would like the initial
> > It was promised that before the import, the public discussion on
> > the mailing list will happen. So far, nothing appeared on either
> > arch@ or current@ providing argumentation why should we accept this.
> Sounds like you're inviting the discussion right now. I'll start =-)
> 1. I hate gcc with the burning heat of a million suns. It's not a
> tool, it's a political weapon wielded by the FSF and their acolytes.
> It's also a crummy piece of software that has been "good enough" for
> far too long. Its development model is a burden to work with and has
> been a major liability towards FreeBSD releases in the past. Its
> demise cannot happen soon enough.
> 2. Due to the political bent of the GPL3 and the FSF's insistence
> on shoving it down everyone's throats, FreeBSD is stuck with a
> dead-end version of gcc. This has already been a liability in terms
> of addressing bugs in gcc itself, and it will only get worse as
> technology moves forward and gcc stands still.
> 3. Clang/LLVM has an active development base and a clear future. It
> will move forward while gcc rots. There simply is no future left in
> gcc unless the FreeBSD project decides to embrace the GPL3, and that's
> a move that has already been heavily discussed, debated, and decided
> on. Anecdotally, I think that FreeBSD is benefiting from shunning the
> GPL3; it's made it an attractive option for companies looking for an
> unencumbered OS for their products.
> 4. While Clang is immature now, it will mature in the near future,
> and FreeBSD will benefit from that process. FreeBSD will get built-in
> access to upcoming technologies like GCD+Blocks and better code
> editors and development tools that gcc will never support. It'll break
> free of the development stranglehold that exists within gcc. Clang has
> shown good agility in adapting to the needs of FreeBSD and the legacy
> of gcc, thanks in large part to the efforts of people like Roman. Gcc
> has been nothing but drama and headache, even with the valiant efforts
> of people like Alexander Kabaev.
> 5. If all of this turns out to not be true and Clang/LLVM fails,
> FreeBSD has lost nothing and can remove it from the base system. Gcc
> remains where it is for now, at least until it's time for the "remove
> gcc discussion".
> The future is !gcc. Putting Clang+LLVM into a position where it can
> be easily embraced by FreeBSD users will greatly benefit the FreeBSD
I do not object to a single point in your message. On the other hand, all
said could be labeled as distilled propaganda.
My main concern is the usefulness of HEAD for routine bug-fixing process.
The proposed merge makes it relatively easy for users to start compiling
the system with CLang. Our HEAD userbase is one of the most valuable
project asset to ensure the quality of the system. After the support for
easy compilation with clang is imported, some substantial portion of the
HEAD users definitely start experimenting with it. This immediately makes
the bug reports against HEAD almost useless, since level of demotivation
when looking at the bug is immense. When you do know that the issue can
be in the compiler, and not the OS, why looking ?
Any bug analisys now shall start with exchange to verify which compiler
was used to build the reporter system, and ask to reproduce it with gcc.
[I am talking not only about gnats, but also mailing list questions,
private pleas for help etc].
My personal opinion is that pushing the import now at the present state
of clang makes a disservice to FreeBSD, and possible clang. Why not keep
the glue on the branch as it is ? Motivated testers willing to help
definitely can checkout from the branch. Import can happen when we are
satisfied with the quality of new compiler, instead of discontent about
Rather, I would consider the changes to ease the use of any external
compiler, from ports or whatever, bent into shape and kept up to date
with system progress very important, much less controversial and more
useful. Then, addicts of any kool-aid-compiler can drink their potion
without starting undesired relations. Unfortunately, this is not what
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100531/2ee4ab31/attachment.pgp
More information about the freebsd-current