[regression] fails to build from source after deleting generated files #4151
Comments
pabs commented Looks like this commit is at fault, please revert it: https://github.com/Warzone2100/warzone2100/commit/d13bc0de7dd0588351af24dc45d55110d0eed6e8.patch |
pabs commented This also means that any distributors of warzone2100 3.1.1 binary packages based solely on warzone2100 3.1.1 released tarballs are violating the GNU GPL. I can't upload this to Debian until this is fixed. |
clueless commented Replying to Warzone2100/old-trac-import#4151 (comment:2):
I find this and odd statement, in what way does it violate gpl? |
clueless commented I mean I built it from source from the tarball and all the files in the tarball are source files not binary blobs like closed source releases. |
pabs commented Your patch to remove the bison/flex dependencies also removed some of the source code from the tarball. The files (bison/flex source) listed below are the source code of the C++ files that were generated from them. They are missing from the tarball and therefore anyone distributing only the tarball is not distributing the complete source and therefore violating the GPL when they build and distribute binaries built from that source. In addition, even if distributors manually copy the files listed below into their distributions, your build system is missing the parts needed to convert the bison/flex code to C++ code, which is required as per GPLv2 item 3 ("plus the scripts used to control compilation and installation of the executable"). Here is a general guide to source issues, once I've fixed my account issues on that wiki I will fix it to mention bison/yacc/flex. http://www.freedesktop.org/wiki/Games/Upstream/#source The reason that the game still builds and works is that you committed generated C++ code to your version control system and still ship it in the tarball but don't ship the bison/flex source for it in the tarball. So your statement "all the files in the tarball are source files" is incorrect. This is very similar to the GNU Emacs GPL violations caused by Emacs upstream a few years ago: https://lwn.net/Articles/453374/
|
clueless commented sorry? what patch? I didn't include a patch? |
pabs commented The patch I linked to in comment:1: https://github.com/Warzone2100/warzone2100/commit/d13bc0de7dd0588351af24dc45d55110d0eed6e8.patch This one too: [372]eff6693e633e8d0d1d0b8a9ceb996a5c3f49f.patch |
clueless commented oh, by stating 'your patch' I thought you were talking about me, not the devs |
pabs commented I thought you were one of the devs, the one who wrote the patches in fact. |
clueless commented looks like a simple oversite.
|
pabs commented Personally I would suggest reverting the commit entirely. Adding generated code/data to VCSes is a recipe for disaster. |
clueless commented I did a quick test to see what happens if you revert that and it looks like autotools fails unless you go back to a version that those commits talk about. maybe this is why the version in Ubuntu is so very old? I also noticed they got some other build files that are not included in the tarball and nobody told them that they are missing before but it seems those are for macs and maybe they are not needed? |
pabs commented The Ubuntu version is old because they just copy the Debian package and Debian hasn't updated it yet. I'm the maintainer of the Debian package and I haven't updated it yet because of this issue, other issues and lack of time. |
clueless commented ah cool! nice to meet you! |
cybersphinx changed blocking which not transferred by tractive |
cybersphinx changed blockedby which not transferred by tractive |
cybersphinx commented Replying to Warzone2100/old-trac-import#4151 (comment:1):
As mentioned in the referenced ticket #3538, automake made an incompatible change in version 1.12. Do you know a way to make the build system support automake 1.11 (which is at least in the current stable Debian and LTS Ubuntu) and 1.12+ while using flex/yacc? |
pabs commented A 5 minute web search found these ways: https://lists.gnu.org/archive/html/automake/2012-07/msg00048.html The second one looks cleaner to me, it checks the automake version in autogen.sh and for older automake it creates a compatability layer. This needs to be repeated for each bison parser. |
vexed commented Replying to Warzone2100/old-trac-import#4151 (comment:11):
Whoops, yeah, this is a minor oversight, and will be corrected as soon as someone gets some free time to make a new tarball. However, reverting doesn't solve any of the issues talked about in the original patch. Clueless, thanks for the patch. Replying to Warzone2100/old-trac-import#4151 (comment:9):
... sigh |
pabs commented See comment:16 for a simple method to solve the issues mentioned in the original patch (automake 1.12 compat issues). If there are other issues, I failed to find them, sorry. By "make a new tarball" I hope you mean make a new 3.1.2 release, never a good idea to modify a tarball after release. What do you mean by "are being replaced"? It would be interesting to read your plans in this area. Did you report bugs about the bison/flex code generation issues you encountered? |
vexed commented Because of the lack of free time, and for the time being, I have uploaded the inadvertent missing files to warzone2100-3.1.1_extra_dist.tar.xz @ our normal host @ SF. There was no script that was used, it was all done by hand, since we had to fix the files for all build systems that we support. As for reporting bugs, latest version of Bison & flex for windows is way behind what is available on linux distros. So, besides asking nicely for a new version... no. As I mentioned, we want all supported platforms to use the exact same code, so, it isn't a option to use different versions on different platforms when the output is different. They are being replaced, as in, we are phasing it out. Most everything will be moved to JS instead, or outright avoided (like lazy texture loading) but this is getting outside the scope of this ticket, please take it to forums for development discussions. |
vexed changed status from |
vexed changed owner from `` to |
vexed changed resolution from `` to |
vexed committed [63] In Warzone2100/warzone2100@63b1860:
|
resolution_fixed
type_bug
| by pabsWhen deleting generated files (inc lib/framework/resource_lexer.cpp) I get this error:
This is a regression from 3.1.0, here is the diff from the previous version, please revert it:
Issue migrated from trac:4151 at 2022-04-16 11:40:02 -0700
The text was updated successfully, but these errors were encountered: