[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190620203845.GA102280@archlinux-epyc>
Date: Thu, 20 Jun 2019 13:38:45 -0700
From: Nathan Chancellor <natechancellor@...il.com>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Doug Anderson <dianders@...gle.com>,
Matthias Kaehlcke <mka@...omium.org>,
Tom Roeder <tmroeder@...gle.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
LKML <linux-kernel@...r.kernel.org>,
Raul E Rangel <rrangel@...omium.org>,
Tom Hughes <tomhughes@...omium.org>,
Ryan Case <ryandcase@...omium.org>, Yu Liu <yudiliu@...gle.com>
Subject: Re: [PATCH] gen_compile_command: Add support for separate
KBUILD_OUTPUT directory
On Thu, Jun 20, 2019 at 01:25:36PM -0700, Nick Desaulniers wrote:
> On Thu, Jun 20, 2019 at 1:13 PM Doug Anderson <dianders@...gle.com> wrote:
> > On Thu, Jun 20, 2019 at 12:53 PM Nick Desaulniers
> > <ndesaulniers@...gle.com> wrote:
> > >
> > > I do miss Doug's Kbuild caching patches' speedup.
> >
> > You actually get quite a bit of this by grabbing a new version of
> > ccache (assuming you use ccache). :-P You still have to pay the
> > penalty (twice) for all the options that are tested that the compiler
> > _doesn't_ support, but at least you get the cache for the commands
> > that the compiler does support.
>
> Hello darkness my old friend:
> https://nickdesaulniers.github.io/blog/2018/06/02/speeding-up-linux-kernel-builds-with-ccache/
> Man, that post has not aged well. Here's what we do now:
> https://github.com/ClangBuiltLinux/continuous-integration/blob/45ab5842a69cb0c72d27d34e73b0599ec2a0e2ed/driver.sh#L227-L245
>
> > Specifically, make sure you have a ccache with:
> >
> > * https://github.com/ccache/ccache/pull/365
> > * https://github.com/ccache/ccache/pull/370
>
> Oh! Interesting finds and thanks for the pointers. Did these make it
> into a release version of ccache, yet? If so, do you know which
> version?
>
It should be available in 3.7 if I am reading git history right.
Cheers,
Nathan
> > I still have it in my thoughts to avoid the penalty for options that
> > the compiler doesn't support but haven't had time to work on it
> > recently.
>
> It had better not be autoconf! (Hopefully yet-to-be-written GNU C
> extensions can support feature detection via C preprocessor)
> --
> Thanks,
> ~Nick Desaulniers
Powered by blists - more mailing lists