Thanks for spotting the thread. Of course this would need a lot of work, moreover someone could write a CMake one too (this is the one that can generate project files out of the box, and is said to be a decent tool also), and maybe some other, so you can compare. Nevertheless, lets push that a little step forward.
Yes, installation, this is an interesting feature ;)
Added directory configuration, install targets and shell starters generation, example:
scons prefix=/usr/local bindir=bin gamedir=games/ufoai install
Note that the directory with data and executables is called gamedir and not datadir -- just doesn't feel like data. One question here is how should radiant be installed.
This requires pk3 generation, so it is partially done (using python's zipfile module) -- it can only recreate zips, can't update them. Appending new files isn't hard, but I don't know how to delete unneeded ones from the archive (I've seen a custom module somewhere that can do that, but haven't tried that yet). By the what are the use cases for pk3's, this is needed only if someone 'make install's or builds one of the installers?
Update-po-radiant went rather easily, could be improved by making a simple builder that would search for xgettext and allow setting gettextdir, Wesnoth has something in this direction:
http://svn.gna.org/viewcvs/wesnoth/trunk/scons/gettext.py.
Update-po: wow, this is quite convoluted, I enjoyed studying those scripts, because I'm not the one who's maintaining them :) My understanding here is that:
- first this generates the message catalog (.pot) by scanning client/game sources, .ufos and .umps; using xgettext in the former case and ufoai.pl in the latter,
- charset=CHARSET should be replaced by charset=UTF-8,
- if the new file and the old file differ only in creation date line, then the .pot is not replaced,
- file paths need to be relative to the src directory,
- in the end it merges .pot with each translation.
Is this right or am I missing something? Why ufo and radiant have their rules so different (different base, with and without a header, different options, update-po-radiant not msgmerging .po-s)?
I've been seriously considering just running make here, but in the end managed to get a .pot that diffs in just a few lines compared to the make's one (five within the header: names of source/base partial .pots, creation dates and one msgid for m_node_base.c:190, which po-check apparently misses; uforadiant.pot comes out 100% same provided you add --sort-by-file and --no-wrap to the makefile rule). The solution uses OTHER_STRINGS and ufopo.pl (which it shouldn't -- would be cleaner and faster to write a small builder for that), but ignores POTFILES.in, FINDUFOS etc. completely -- just globs for client/game/radiant sources instead (or uses a list constructed earlier when appropriate). Please, note that if you change a translatable string in source and just type 'scons' it will refresh the .pot and update .po-s; might be a little scary, but I'd say this is the right thing to do (this is because compiled translations are set as a default target and it can figure out that they depend on .po-s and these depend on .pot; also xgettext, msgmerge or msgcat commands don't have a builder, so need to be in path and don't pretty print yet).
Also:
- aliases for some targets (client, server, game, ufo2map, radiant, langs, maps, archives, install, update-po, update-po-radiant); you can always use the target name also, but with maps this would be inconvenient ;) ,
- fixed some FIXMEs,
- and most importantly: written a list of tasks that need to done before this is usable (inside the SConstruct).
It has become somewhat big and slow already (that is the null build takes more than it could take), partly due to my lousy programming -- there's no optimization in the SConscript itself -- some parts of it often don't need to be analyzed (for example: unless it's install there is no need to parse install rules). Moreover, I have to admit that the script needed adding shared/parse.c manually to sources' lists (can't glob 'shared' because different parts use different files therein).
[attachment deleted by admin]
