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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan

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