Re: [RFC PATCH 00/50] tools/perf: Speed up the build system

[Ingo Molnar <mingo@kernel.org>]

* David Ahern <dsahern@gmail.com> wrote:

> > This is just the print-out though - the actual feature logic should 
> > still follow the NO_DWARF=1 setting (modulo bugs).
> >
> > So I'm wondering, should we solve this by adding extra logic linking 
> > the feature flags with their legacy names. It would get unwieldy 
> > rather quickly I think.
> 
> yes.
> 
> > Another solution would be to introduce a new method to disable 
> > features, via something like:
> >
> >	make FEATURE_dwarf=0
> >
> > Where the pattern would follow the auto-detected naming. This would 
> > simplify the printout logic and would simplify the feature support / 
> > flags decision tree as well.
> >
> > Furthermore, it would unify the various flags we have today, which is 
> > rather mixed: for example there's NO_DWARF which is a name that shows 
> > negated logic, but there's also HAVE_CPLUS_DEMANGLE_SUPPORT is is a 
> > name with positive logic. We'd have one uniform naming scheme 
> > permeating the whole build system.
> 
> The Kconfig series converts all of the NO_XXXXX to CONFIG_XXXXX. I'd 
> like to see that because it mirrors kernel configs and is a stepping 
> stone to kconf integration.

Yeah.

It also negates NO_XXXXX use back to straight logic, right?

I.e. CONFIG_LIBSLANG=y should mean that libslang is enabled, 
CONFIG_LIBSLANG undefined means that it's disabled.

These could then also be passed straight to the build system:

  make CONFIG_LIBSLANG=0

should have the same effect as NO_LIBSLANG. The old NO_XXXXX flags would 
go away.

Maybe we could also force features on via:

  make CONFIG_LIBSLANG=1

this could be used to work around auto-detection failures, and could be 
used to check whether a feature check is precise.

This:

  make CONFIG_ALL=1

could perhaps be a handy shortcut to force-enable all features [that make 
sense on an architecture] - for package builds.

> If the NO_XXXX takes precedence over the autoprobe detection then the 
> user gets what is asked, so I guess we can leave it as is for now.

Okay. I'll try to leave it alone as much as possible, to not upset your 
kconfig series even more ...

Thanks,

	Ingo