On Tue, 27 Nov 2012, Mike Stump wrote: > A review of the change and approval of the change should be enough to > catch issues going into the FSF tree. The build should just copy the > generated file to the source tree, if changed. The build failed for me,
The rule from the FSF is that tm.texi is treated more like a source file than a generated file, because no actual dual-licensing notice for target.def could be produced (if it could, we wouldn't need a checked-in tm.texi at all - checked-in generated files are only for cases where they are needed in the bootstrap process or to reduce the external dependencies for a build). Someone can write new text and put it in both places for licensing in each source file under its respective license - the makefile rules are providing a tool to assist someone choosing to do so and so ensure that the source files target.def, tm.texi.in, tm.texi are kept in sync in a way that we wish to keep them in sync. Or someone can copy existing doc strings from tm.texi to target.def, or from comments to both target.def and tm.texi, keeping the three files in sync in the desired way, but with approval for the patch from one of the docstring relicensing maintainers being required in that case. Thus, the makefile rules are not rules for updating a generated file in the usual sense - they are rules to assist developers, who have made a conscious decision to put the same text in multiple source files under different licenses, in making changes to those multiple source files in sync with each other. Perhaps the error message should be phrased differently to make clear that it is about the three source files not being in sync with each other. -- Joseph S. Myers jos...@codesourcery.com
