Messages in this thread | | | Date | Sun, 23 Feb 2014 13:55:52 -0800 | From | Josh Triplett <> | Subject | Re: [PATCH v2 2/2] x86: Support compiling out human-friendly processor feature names |
| |
On Sun, Feb 23, 2014 at 01:44:20PM -0800, H. Peter Anvin wrote: > On 02/23/2014 01:32 PM, Josh Triplett wrote: > > > > 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. > > > > Why did it fail to build mkcpustr? It would seem that mkcpustr is or at > least ought to be completely agnostic to any of these options. > > The extra build machinery here seems completely pointless. > > I agree that the #ifdef isn't a big deal, but all this extra machinery > really indicates something is odd. > > Oh, and of course, looking at the v2 patchset, the problem is the ifdef > around the mkcapflags shell script which really shouldn't be necessary. > We may have to add a rule to force capflags.c to be built even if > capflags.o is not requested, but that is fine. > > That will cut down on the Makefile hacks considerably, and will avoid > this problem completely.
Why have the build system waste time building several things that won't be used? It seems like the Makefiles are exactly where we *should* have the ifdef machinery, rather than in source. I'd happily add another ifdef in the Makefile rule that builds cpustr.h, to generate a stub cpustr.h header, and then remove one more ifdef in the source.
- Josh Triplett
| |