[OS-BUILD PATCH] redhat: relax configchecks for gcov build

[Jan Stancek (via Email Bridge)]

From: Jan Stancek <jstancek(a)redhat.com&gt;

redhat: relax configchecks for gcov build

gcov build patches config file during build, which can lead to
configchecks failing with either unset variable or because it
finds a difference between options in source tree and buildroot.

Relax the check for gcov builds to prevent build failures and need
to define config options in source tree also for non-gcov builds.
This impacts only gcov-related options, since default (non-gcov)
build still runs configchecks and gcov is using same tree.

Signed-off-by: Jan Stancek <jstancek(a)redhat.com&gt;

diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -258,6 +258,7 @@ Summary: The Linux kernel
 
 # turn off debug kernel and kabichk for gcov builds
 %if %{with_gcov}
+%define with_configchecks 0
 %define with_debug 0
 %define with_kabichk 0
 %define with_kabidupchk 0

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1433

[Don Zickus (via Email Bridge)]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1433#note_7065...

I ran into this too.  I am not a fan of this approach.  It solves the problem,
sure.  However, part of the problem is that the gcov stuff is hidden behind
the spec file magic.  This makes it difficult to detect and resolve and leads
to changes like this.

Not sure if we can apply gcov config changes during 'make dist-srpm-gcov'?

[Jan Stancek (via Email Bridge)]

From: Jan Stancek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1433#note_7066...

I think reason for handling this as build option (in spec file) was that you
could build everything from one srpm. Right now we have 'generic' and
'debug'
config variants, we could add 'gcov' to it. That would catch errors during
config generation, even if you don't build gcov kernel.

[Jan Stancek (via Email Bridge)]

From: Jan Stancek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1433#note_7079...

I'm exploring the idea of new config variant, so far ran into !1436 and !1437

[Don Zickus (via Email Bridge)]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1433#note_7081...

@jstancek - i tried to spend about a half hour thinking about this.  As I saw
other config changes using 'sed' in the kernel.spec file, I thought about
using something like kernel.local but calling it kernel.gcov.  Playing with
the idea started to add some complexity.

Mainly, I was frustrated that I had to see the failures in Brew instead of
locally with some sort of 'make dist-configs' variant.  And with your change I
am not sure if that hides other things that should be enabled.  For example
CONFIG_GCOV_PROFILE_ALL would have been disabled if it wasn't already
explicitly enabled in the spec file.

Meanwhile the only option missing is
redhat/configs/common/generic/CONFIG_GCOV_PROFILE_FTRACE.

I think I am ok with just adding the above config to the sed line and moving
along.

Though I see where you are going with the gcov variant idea.  I wonder if that
causes issues later with -rt and -auto variants later.

Thoughts?

[Jan Stancek (via Email Bridge)]

From: Jan Stancek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1433#note_7092...

>  I am not sure if that hides other things that should be enabled
It does, but gcov was always best-effort kind of feature. It's not built by
default in ARK or RHEL. So I didn't think anybody would mind.

>  I wonder if that causes issues later with -rt and -auto variants
> later 
Potential issue with full gcov variant is that number of configs could expand
a lot if you add more variants. Since each variant would also have gcov
variant.

>  I thought about using something like kernel.local but calling it
> kernel.gcov 
I was thinking about something similar as well. I'll push what I'm trying at
the moment. It's using config tools to build/verify full gcov config during
srpm creation - so config check targets should catch any issues.
But it uses only partial gcov config in SRPM and then merges it on top of
current config, similar to kernel.local.