Fullmoon build

[cazfi]

Hello

In Open Source community I have been most active in Freeciv ( http://www.freeciv.org/ ) development, but I also run a
couple of one-man projects, and have made minor contributions to other projects. One of the projects of my own is fullmoon ( http://www.cazfi.net/fullmoon ) build tool for linux.

I'm now adding Warzone 2100 build as "test case" (lives in examples" -directory) for fullmoon. I hope that my efforts on that front will also benefit Warzone 2100 project quality.

Here are my findings in Debian Wheezy amd64 about Warzone 2100 build so far. In case it matters, builddir != srcdir:

- Normal (typical) build works perfectly out-of-the box

- Configure gives warning:
"configure: WARNING: a2x or wkhtmltopdf not found, can't convert documentation. This doesn't affect building the game,
but means that things like "make dist" and building a Windows installer will fail."
even after I installed debian packet wkhtmltopdf. Is this known problem you know solution offhand, or should I investigate it a bit?

- "make distcheck":
- Without prior build in tree:

bison -y -d -oresource_parser.tab.hpp ../../../src/lib/framework/resource_parser.y
../../../src/lib/framework/resource_parser.y: warning: conflicting outputs to file `resource_parser.tab.hpp'
/usr/bin/moc-qt4 -o wzapp_moc.cpp ../../../src/lib/framework/wzapp.h
flex -oresource_lexer.lex.cpp ../../../src/lib/framework/resource_lexer.l
flex -ostrres_lexer.lex.cpp ../../../src/lib/framework/strres_lexer.l
cp: cannot stat `../../../src/lib/framework/resource_parser.tab.cpp': No such file or directory
make[1]: *** [distdir] Error 1

- After build in tree:

cp: cannot stat `../../src/po/../../src/po/ca_ES.gmo': No such file or directory
make[2]: *** [dist2] Error 1


- I see you use parameter "--foreign" for automake in autogen.sh. As I accidentally run automake without it, I noticed that among missing files that "--foreign" forgives was ABOUT_NLS. As you use gettext, I wonder if that omission is intentional?
For the record, other missing files are:
- INSTALL (automake has capability to add latest version of standard INSTALL if requested)
- NEWS
- README

[cybersphinx]

In Open Source community I have been most active in Freeciv ( http://www.freeciv.org/ ) development, but I also run a
couple of one-man projects, and have made minor contributions to other projects. One of the projects of my own is fullmoon ( http://www.cazfi.net/fullmoon ) build tool for linux.

I'm now adding Warzone 2100 build as "test case" (lives in examples" -directory) for fullmoon. I hope that my efforts on that front will also benefit Warzone 2100 project quality.

We do have a buildbot set up for automatic builds.

- Configure gives warning:
"configure: WARNING: a2x or wkhtmltopdf not found, can't convert documentation. This doesn't affect building the game,
but means that things like "make dist" and building a Windows installer will fail."
even after I installed debian packet wkhtmltopdf. Is this known problem you know solution offhand, or should I investigate it a bit?

a2x is from asciidoc, I've added a note about that now.

- "make distcheck":
- Without prior build in tree:

bison -y -d -oresource_parser.tab.hpp ../../../src/lib/framework/resource_parser.y
../../../src/lib/framework/resource_parser.y: warning: conflicting outputs to file `resource_parser.tab.hpp'
/usr/bin/moc-qt4 -o wzapp_moc.cpp ../../../src/lib/framework/wzapp.h
flex -oresource_lexer.lex.cpp ../../../src/lib/framework/resource_lexer.l
flex -ostrres_lexer.lex.cpp ../../../src/lib/framework/strres_lexer.l
cp: cannot stat `../../../src/lib/framework/resource_parser.tab.cpp': No such file or directory
make[1]: *** [distdir] Error 1

For some reason, "make dist" is too stupid to recognize that it needs to run the flex/yacc stuff, while it works for a normal build.

- After build in tree:

cp: cannot stat `../../src/po/../../src/po/ca_ES.gmo': No such file or directory
make[2]: *** [dist2] Error 1

Not sure, that might need a full build in the source directory first, or a "make -Cpo update-po".

- I see you use parameter "--foreign" for automake in autogen.sh. As I accidentally run automake without it, I noticed that among missing files that "--foreign" forgives was ABOUT_NLS. As you use gettext, I wonder if that omission is intentional?
For the record, other missing files are:
- INSTALL (automake has capability to add latest version of standard INSTALL if requested)
- NEWS
- README

We removed most included documentation a while ago since it was continuously outdated anyway, and I don't think the generic files add much useful info.

[cazfi]

I suspect that yacc/flex problems are caused by bad interaction between automake's internal support for those tools and your own implementation of their handling. I'm not entirely sure if your implementation even should work, or is it outright erronous.
I think right thing to do here would be to use automake's automagic yacc/flex support, at least if having intermediate files named like xxx.c instead of xxx.tab.c will not cause major rework in other parts of codebase.

Failure to copy .gmo files seems like srcdir != builddir problem. Those .gmo files have been generated to builddir, but cp tries to access them from srcdir.

[cybersphinx]

I suspect that yacc/flex problems are caused by bad interaction between automake's internal support for those tools and your own implementation of their handling. I'm not entirely sure if your implementation even should work, or is it outright erronous.
I think right thing to do here would be to use automake's automagic yacc/flex support, at least if having intermediate files named like xxx.c instead of xxx.tab.c will not cause major rework in other parts of codebase.

Possibly. If you know how to fix this, you're welcome, nobody of us was bothered enough by it to (successfully) investigate.

Failure to copy .gmo files seems like srcdir != builddir problem. Those .gmo files have been generated to builddir, but cp tries to access them from srcdir.

Yeah. Same as above, if you have a build rule that, if a file exists in srcdir, copies it to builddir, if not or if the source file is newer than the copy in srcdir regenerates it, we'd very much welcome it (there should be a ticket for that somewhere, and it'd be useful for another case as well).

[cazfi]

.gmo file part was already fixed in tickets, leaving only yacc/lex stuff. I'm testing a patch to use automake's yacc/lex support instead of rolling our own. I'm currently testing only native linux build using autotools, don't know how much I have resources to test anything else, though my changes are very likely to break something. Files, both present and generated, had to be renamed due to how autotools determine things from file suffix:
- Generated header files have suffix ".h" instead of ".hpp"
- Source files generated with yacc have suffix ".cpp" instead of ".tab.cpp"
- Yacc files have suffix ".ypp" instead of ".y" -> automake will produce ".cpp" instead of ".c" -> it will be compiled as c++ file and not as c-file. I assume this is required as existing system produces .cpp files.
- Lex files have suffix ".lpp" instead of ".l" for same reason as yacc files have ".ypp"

[cazfi]

Here's the patch to use automake yacc/lex stuff. Before applying this patch .l files must be renamed as .lpp, and .y files as .ypp. Autotools build works, I've had no resources to test any other build methods and have done nothing to fix them -> they are certainly broken. In addition to renaming original .l and .y files as .lpp and .ypp, generated headers are expected to have suffix .h instead of .hpp. Reasons for these changes are explained in previous post.

Full list of files to rename before applying the patch:

lib/framework:
resource_lexer.l -> resource_lexer.lpp
strres_lexer.l -> strres_lexer.lpp
resource_parser.y -> resource_parser.ypp
strres_parser.y -> strres_parser.ypp

lib/gamelib:
audp_lexer.l -> audp_lexer.lpp
audp_parser.y -> audp_parser.ypp

lib/script:
chat_lexer.l -> chat_lexer.lpp
script_lexer.l -> script_lexer.lpp
chat_parser.y -> chat_parser.ypp
script_parser.y -> script_parser.ypp

src:
level_lexer.l -> level_lexer.lpp
message_lexer.l -> message_lexer.lpp
scriptvals_lexer.l -> scriptvals_lexer.lpp
message_parser.y -> message_parser.ypp
scriptvals_parser.y -> scriptvals_parser.ypp

[vexed]

Hmm, that would break the other build systems...

[dak180]

Hmm, that would break the other build systems...

I would not mind fixing the xcode system if it lead to slightly more sane handling of the yacc/lex stuff alowing me to use xcode's internal support for it.

[cybersphinx]

Yeah, lex/yacc in automake has some quirks as well, and as long as other build systems can be fixed, that's not a valid objection imo. Also, tickets please, so we don't forget patches.

[vexed]

Yeah, lex/yacc in automake has some quirks as well, and as long as other build systems can be fixed, that's not a valid objection imo. Also, tickets please, so we don't forget patches.

That wasn't a objection, just a footnote to see what happens...

[cybersphinx]

See #2936.