[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |