[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-next 6/9] kconfig: add llvm coverage option



On Wed, Nov 08, 2017 at 04:07:35AM -0700, Jan Beulich wrote:
> >>> On 08.11.17 at 09:49, <roger.pau@xxxxxxxxxx> wrote:
> > On Wed, Nov 08, 2017 at 01:13:29AM -0700, Jan Beulich wrote:
> >> >>> On 26.10.17 at 12:10, <wei.liu2@xxxxxxxxxx> wrote:
> >> > On Thu, Oct 26, 2017 at 11:08:21AM +0100, Roger Pau Monné wrote:
> >> >> On Thu, Oct 26, 2017 at 11:03:13AM +0100, Wei Liu wrote:
> >> >> > On Thu, Oct 26, 2017 at 10:19:35AM +0100, Roger Pau Monne wrote:
> >> >> > >  config GCOV
> >> >> > >     bool "Gcov Support"
> >> >> > >     depends on !LIVEPATCH
> >> >> > 
> >> >> > && !LLVM_COVERAGE
> >> >> 
> >> >> That was my idea, but sadly that's not possible because you generate a
> >> >> circular dependency. The best solution that I found is to only mark
> >> >> one as exclusive (ie: have depends !GCOV in the LLVM_COVERAGE option
> >> >> below).
> >> > 
> >> > In that case, why not just use "choice" to let user pick the
> >> > implementation?
> >> 
> >> Plus then this choice should probably have an auto-detect option
> >> just like gcov's gcc version one - at least I assume that it should
> >> be pretty straightforward to tell at build time which variant to use.
> >> In fact - what would happen if one enabled the wrong option for
> >> the compiler in use? IOW I wonder whether auto-detection (and
> >> then also for the gcc version) should be the only valid mode).
> > 
> > I don't plan to introduce llvm/clang version choices here, I think
> > autodetection should be fine.
> 
> And I didn't think about version choices for clang here anyway -
> the point really was just about gcc vs clang.
> 
> > I can remove the gcc ones also, leaving this as a boolean choice (ie:
> > enable code coverage support), but I would like to have some
> > confirmation from the gcc side.
> 
> So let's ask Wei: What was the reason for the Kconfig level
> version choice here in the first place? After all, if the wrong one
> is being selected, the build will fail afaict due to the #error
> directives in the version specific files.
> 

The #error on versions was added in later iterations IIRC. Looking back
I think it would make sense to just have autodetect.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.