svn commit: r232074 - head/sys/cam/ctl

[Alexander Best]

On Fri Feb 24 12, Dimitry Andric wrote:
> On 2012-02-24 10:38, Alexander Best wrote:
> > is the clang version in base able to do complete universe builds for i386 and
> > amd64 without the need for NO_WERROR= and WERROR= now?
> 
> "universe" means all arches, and all kernel configs, so no.  The status
> for head with clang is as follows:

i meant with TARGETS=i386 amd64 set. i think this will only do a universe build
for those arches.

> 
> - buildworld with default options, e.g. no WITH_XXX or WITHOUT_XXX
>   settings, will complete without any (fatal) warnings.
> - buildkernel of the default GENERIC config still has one warning left,
>   in sys/dev/mps/mps_sas.c.  It should be simple to fix, but I'm
>   checking it with Ken first.
> - The LINT kernel configs probably have many warnings left.  I haven't
>   tested those extensively.
> 
> As soon as world & kernel compile without warnings, I'd like to have a
> tinderbox that continually builds with clang.  So head won't be
> regressing any more. :)

yeah good idea. :)

> 
> 
> > ps: are there any plans to add support for compiling kernel+userland with clang
> > tot? maybe this can be accomplished by doing something like
> > 
> > echo "WITH_CLANG_TOT=yes" >> /etc/src.conf
> 
> I'm not working on this at the moment.  Pawel Worach (CC'd) has a
> buildbot setup that builds FreeBSD daily with clang ToT.  Apparently
> just a few patches are needed.
> 
> 
> > which will turn all -Wformat-invalid-specifier and -Wformat-extra-args errors
> > into warnings (because clang tot doesn't support -fformat-extensions)?
> 
> It would be better to push our format extensions upstream, I think.
> Though the option should probably be renamed to something else, e.g.
> -ffreebsd-extensions, or such.

i'm still confused regarding the actual politics regarding this change.
everytime this comes up i get a different answer. the last one was that since
the special printf format is only used for kernel code, the -fformat-extensions
code within clang base shouldn't be pushed upstream.

personally i like the idea of pushing it upstream and renaming it to
-ffreebsd-extensions. that would make it easier to import new clang versions
and it would be a lot easier to build freebsd with clang tot.

maybe pushing the -fformat-extensions code upstream could happen before freebsd
10.0 gets released.

thanks for your answer.

cheers.
alex