Having removed boost::function.hpp we need to replace it with gtkmm2ext/actions.h - otherwise, glibmm/refptr.h can't make sense of the type 'Gtk::ActionGroup' (go figure...)
Rename the worker functions to make it clear that their name in this
case isn't magic. These functions "are not" the waf commands. It is the
custom build context class definitions that define the i18n commands ...
which will invoke these top level worker functions which in turn invoke
the others recursively.
The bare printing of the build environment in the top level i18n command
seems to be old debug code that safely can be removed.
Try to make it a bit more clear what is going on with class and def for
i18n commands.
It was confusing that we first defined i18n classes in the beginning of
the wscript file, and then replaced them with "plain" functions with the
same name at the end. pyflakes also didn't like it.
It seemed magic. The i18n functionality easily broke if trying to touch
that. It deserves an explanation to make it maintainable ... and some
cleanup.
Simple functions in the top level wscript file are generally exposed as
custom waf commands. The command will have the same name as the function
and will get a plain Context. But that simple method doesn't work for
these i18n commands. They have to be declared in a different way with a
custom BuildContext, as seen and described in the comment.
The name of the BuildContext classes doesn't matter, so we change the
name to avoid the name collision and to give a hint how they actually
just are contexts for the commands - they are not the command itself. We
also place the classes next to the corresponding functions so it is more
obvious that they are related.
Regular .h files *should* be self-contained and independent of previous
includes and guarded to only include once. Make it clear which files
that *doesn't* apply for at all.
