Re: stupid build error
On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump mikest...@comcast.net wrote: This: Verify that you have permission to grant a GFDL license for all new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi. make[3]: *** [s-tm-texi] Error 1 make[3]: *** Waiting for unfinished jobs…. is one of the stupidest build errors I've seen all decade. Can someone fix it please? This means someone edited gcc/doc/tm.texi.in and/or gcc/target.def without checking a new version of gcc/doc/tm.texi . This build failure is to make sure we are not violating the rules setup by FSF for the licensing for target.def both GPL and GFDL. Thanks, Andrew Pinski
Re: stupid build error
On Nov 27, 2012, at 1:22 PM, Andrew Pinski pins...@gmail.com wrote: On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump mikest...@comcast.net wrote: This: Verify that you have permission to grant a GFDL license for all new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi. make[3]: *** [s-tm-texi] Error 1 make[3]: *** Waiting for unfinished jobs…. is one of the stupidest build errors I've seen all decade. Can someone fix it please? This means someone edited gcc/doc/tm.texi.in and/or gcc/target.def without checking a new version of gcc/doc/tm.texi . This build failure is to make sure we are not violating the rules setup by FSF for the licensing for target.def both GPL and GFDL. 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, which is wrong, as there if absolutely no change I can make that runs afoul of copyright law, save copying in content for which would be a violation, which is completely uncatchable, so, there is absolutely no way to check for this failure and absolutely every other failure is a false positive, so, again, let me state that the check is wrong. What ever condition people are trying to catch, how they did it is wrong. I mean, we could have a check that fails the build if any source file has been modified. This would catch all new copyright volitions with probability 1; however, we don't do that? Why? Simple, too many false positives. By changing a file, you assert are doing so in a manner consist with law, and that is that. Once so asserted, there _can be_ no non-false positives, ever.
Re: stupid build error
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
Re: stupid build error
On Nov 27, 2012, at 4:50 PM, Joseph S. Myers jos...@codesourcery.com wrote: 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. You failed to state a single case where a violation is caught. Do that now, I'll wait. If I modify the tree in a way that the generated tm.texi file changes, and that file is copied into the source tree, and I distribute it, then, there are only two cases to consider, either, I did that in violation of the copyright law, or I did not. If I did, then, exactly how the law is violated is beyond the grasp of software, or I did not, and in that case, there is no aide to me for failing the build. You're under the mistaken idea that you can write software to catch violations of law, stop. You cannot. Failing the build because I merely _changed_ the software is _not_ an indication of a violation of law is about to take place. If you want to argue that it is possible to catch a violation of law, go for it. For the counter proof, there can be no violation of law, without a copy, or, say, a distribution. I'm not going to distribute, therefore, there can be no violation of law, QED. All failures from any development I might undertake that fail the build in this way, are _always_ false positives. Please fix all false positives.
Re: stupid build error
On Tue, 27 Nov 2012, Mike Stump wrote: You failed to state a single case where a violation is caught. It's not about catching violations of law, it's about catching cases where the source tree is in an inconsistent state. And a not uncommon cause of that is that someone didn't know about the relation between the three source files, target.def, tm.texi.in and tm.texi, and modified tm.texi directly, or modified multiple files by hand inconsistently. (Although the code attempts to use timestamps to distinguish different cases of inconsistency, this can be unreliable, especially if someone checked in an inconsistent state and someone else is building from a tree updated with svn update. So the rule is that in any case of an inconsistency in the source tree, things are passed back to the user to make a determination, based on examining the differences, of how to restore consistency to the source tree - and of whether the resulting patch submission will need docstring relicensing review.) -- Joseph S. Myers jos...@codesourcery.com
