Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD

On Mon, May 31, 2010 at 12:24:52PM +0200, Roman Divacky wrote:
> On Mon, May 31, 2010 at 12:56:17PM +0300, Kostik Belousov wrote:
> > 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_at_ or current_at_ 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
> > > project.
> > >
> > > Scott
> > >
> > 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].
>  
> agreed. what do you propose to help identify/prevent situations when
> people are reporting bugs coming from a compiler problem rather than
> those from a genuine src problem?
If I have a good idea how to help a situation, I would described it. It
is very strange and worrying that you, who are pushing the import, ask
somebody about plan on identifying and handling the compiler bugs. I
would expect you to have a solid plan before the import. This lowers my
confidence in the proposal even further.

> 
> people are already experimenting with clang installed from ports,
> with gcc4.{3,4,5} from ports etc. by not importing clang we can
> maybe delay this a little but it's coming anyway.
I am pretty much fine and happy with people experimenting with clang
or any other compilers from ports, custom built, whatever. This is very
different from importing some compiler into base. See below about "signal".

> 
> > 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
> > old one.
>  
> people have been testing stuff and identified bugs. those bugs were fixed.
> there are sure some more but we need wider exposure to identify those
> new bugs and also clasify them.
But I object to sacrificing the FreeBSD development and test cycle
to the clang development and test cycle. When the compiler becomes
stable enough to not think first about bug in the compiler, and only
then considering the bug in the compiled program, it can be used for
non-compiler development.

If somebody wants to do clang development, why should she develop it
in FreeBSD repo, or under the coverage of FreeBSD project, instead of
clang project ? Put it another way, why FreeBSD developer have to
debug clang instead of debugging FreeBSD ?

> 
> the amount of people who are willing and able to checkout and test external
> branch is minimal. I feel we are at the point where more exposure is
> necessary.
> 
> by importing we are sending a strong signal to various 3rd parties to show 
> in what way we are moving. importing sooner rather than later also ensures 
> that the compiler will get much more tested (and thus stable) by the day
> 9.0R happens.
Yes, we do send a signal, and the signal is too strong IMO. 

> 
> > 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
> > happen.
> 
> this is orthogonal to this. we as a project aim for delivering complete
> operating system and we just need a system compiler. gcc4.2.1 just
> cant serve us anymore, we need to do something now.
Please describe why gcc in base cannot serve us anymore while served up
to the minute I got your message.