Add a test to check that the built makefile uses tabs properly #750

petdance opened this Issue Mar 26, 2012 · 2 comments


None yet

3 participants


From a mail to parrot-dev from @jkeenan:

Second, you may recall that in makefiles hard-tabs are significant. It often seems, however, that one can get away with leading wordspaces where a leading hard-tab is what is "officially" required. I know that in past cleanups of the makefile templates I have substituted leading hard-tabs for leading wordspaces with no change in functionality. Here, however, we have a case where the leading hard-tab is crucial. Why? Because in the two code segments in the question the first line in the template file ends with '$(MINIPARROT)' while the second begins with '[hard-tab]$(MINIPARROT)'. If one is not paying attention to the hard-tab, one can come to the incorrect conclusion that the second '$(MINIPARROT)' is redundant and can be removed -- which is what I did, and which is what worked until nine tested with '-j6'.

Implication: We should add something to the documentation for config/gen/makefiles/ (and perhaps other files) to alert people to this possible source of error. I will do that now.

We should have a t/*.t file that verifies tab usage.

jkeenan commented Mar 27, 2012

Notwithstanding the diagnosis I provided, I say "-1" to a new coding standards test aimed at guaranteeing proper tab placements in our makefile templates. Reason: YAGNI.

I cannot recall any other times in the past six years when the build was broken because of "hard tabs vs. wordspaces." This build problem got fixed within 36 hours of its first being noticed. So if the harm caused by the error was small, the benefit to preventing the error's recurrence will also be small.

We have to balance that modest benefit against the effort it will take to (a) agree, before writing a coding standards test, on how to modify the coding standards document; (b) write the new test file; and, most crucially, (c) guarantee that it works across 'gmake', 'bsdmake', 'nmake' and all the other variants are users/developers are likely to want to use. I don't think the potential benefit warrants that effort.

To the best of my recollection, most of our current coding standards existed at the time I joined the Parrot project 5-1/2 years ago. Though I'm often cast in the role of coding standards enforcer, I didn't make the standards up. In very few cases did I write the Perl code in the test files. Mostly, I've just refactored them as needed.

More to the point, what we would really benefit from is to have our developers who work on our .c, .h and .pmc source code files:

(a) run 'make nocritic_codetest' before committing; and

(b) better still, work in branches rather than directly on master.

I don't mind doing cage cleaning, but sometimes even I get tired of having to clean up after people who develop directly in master and who are perfectly capable of running 'make codetest' but fail to do so. If someone posts that they've been working in a branch and want to merge it soon, I am perfectly agreeable to helping bring that branch up to coding standards before it gets merged into master.

In short, I think our best course of action is to have more self-enforcement of the existing coding standards rather than imposing additional standards whose benefits are small.

Thank you very much.
Jim Keenan


I'm all for self-enforcement (including and especially me).

As to my original question, I understand it might be YAGNI, but if the cost is small, I don't mind paying it as a one-time cost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment