Re: [PATCH v2 2/2] x86: Support compiling out human-friendly processor feature names

[Josh Triplett <josh@joshtriplett.org>]

On Sun, Feb 23, 2014 at 09:56:56AM -0800, H. Peter Anvin wrote:
> On 02/22/2014 01:36 PM, Josh Triplett wrote:
> > 
> > No, even after removing the ifdefs around the build rules as you
> > suggested (and v3's fixes for the resulting build issues, notably
> > changing some -y's to -$(CONFIG_X86_FEATURE_NAMES)), the makefiles still
> > manage to not build mkcpustr or cpustr.h, because nothing depends on it.
> 
> How could it miss the rule:
> 
> $(obj)/cpu.o: $(obj)/cpustr.h

Because, in order to un-break the build, v3 wraps an ifdef around that
dependency, to prevent building cpustr.h.  Otherwise, the rule for
cpustr.h tries and fails to build mkcpustr.

> > I could change the build rules to generate an empty cpustr.h and avoid
> > this ifdef, but that'd require an additional ifdef block in the Makefile.
> 
> Typically the way it is done is to generate the #ifdef *inside*
> cpustr.h.  However, cpustr.h is kind of special anyway so it probably
> doesn't matter.

Given that only one file includes cpustr.h, and that seems unlikely to
ever change, moving the ifdef inside the header doesn't seem that
worthwhile.  If it were included more than once, it would definitely
make sense to generate a stub header.

- Josh Triplett