It is not necessary: when a rule has multiple commands in it, GNU Make
(which ELinks requires anyway) runs them one at a time, regardless of
the -j option, and skips the remaining commands when one of them
fails, regardless of the -k option. These options take effect at the
level of targets rather than individual commands.
http://elinks.cz/community.html says bugs should be reported
to elinks-users but patches should be sent to elinks-dev.
I guess elinks-users is more appropriate here.
This is so that contrib/mkdist need not delete that explicitly
(although it still does, in order to do the right thing with
a few older versions too).
The file could apparently be removed altogether (see recent
emails on elinks-dev) but a small change like this is less
likely to cause any surprises.
These are the same functions whose argument strings xgettext should
add to elinks.pot. I also searched for uses of the functions that are
known to take format strings, in case the callers might take the
format string from the result of another function, but didn't find any
new ones.
I constructed the list by grepping for "..." and looking for related
macros and va_list functions. Also grepped for "*fmt", and "*format"
but the extra functions found that way (add_date_to_string,
format_command, subst_user_agent, etc.) handle format strings that
don't have the same syntax as in printf: in particular, type safety
does not depend on the order of format specifiers like it does in
printf. Therefore, these format strings should not be subjected to
the "c-format" checks of msgfmt.
It has no useful effect here, because Make runs the next command in
a separate shell process that does not inherit the working directory
from this one.
now be specified as --srcdir=top_srcdir (or --source-directory=top_srcdir
or -S top_srcdir). Changed po/Makefile to match.
This option can even be repeated; that resolves a BUGS item.
Changed po/Makefile to ignore exit codes from check-accelerator-contexts.pl.
Enabled bundling of options in Getopt::Long so that -Stop_srcdir works too.
the same accelerator key to multiple buttons in a dialog box or
to multiple items in a menu. ELinks already has some support for
this but it requires the translator to run ELinks and manually
scan through all menus and dialogs. The attached changes make it
possible to quickly detect and list any conflicts, including ones
that can only occur on operating systems or configurations that
the translator is not currently using.
The changes have no immediate effect on the elinks executable or
the MO files. PO files become larger, however.
The scheme works like this:
- Like before, accelerator keys in translatable strings are
tagged with the tilde (~) character.
- Whenever a C source file defines an accelerator key, it must
assign one or more named "contexts" to it. The translations in
the PO files inherit these contexts. If multiple strings use
the same accelerator (case insensitive) in the same context,
that's a conflict and can be detected automatically.
- The contexts are defined with "gettext_accelerator_context"
comments in source files. These comments delimit regions where
all translatable strings containing tildes are given the same
contexts. There must be one special comment at the top of the
region; it lists the contexts assigned to that region. The
region automatically ends at the end of the function (found
with regexp /^\}/), but it can also be closed explicitly with
another special comment. The comments are formatted like this:
/* [gettext_accelerator_context(foo, bar, baz)]
begins a region that uses the contexts "foo", "bar", and "baz".
The comma is the delimiter; whitespace is optional.
[gettext_accelerator_context()]
ends the region. */
The scripts don't currently check whether this syntax occurs
inside or outside comments.
- The names of contexts consist of C identifiers delimited with
periods. I typically used the name of a function that sets
up a dialog, or the name of an array where the items of a
menu are listed. There is a special feature for static
functions: if the name begins with a period, then the period
will be replaced with the name of the source file and a colon.
- If a menu is programmatically generated from multiple parts,
of which some are never used together, so that it is safe to
use the same accelerators in them, then it is necessary to
define multiple contexts for the same menu. link_menu() in
src/viewer/text/link.c is the most complex example of this.
- During make update-po:
- A Perl script (po/gather-accelerator-contexts.pl) reads
po/elinks.pot, scans the source files listed in it for
"gettext_accelerator_context" comments, and rewrites
po/elinks.pot with "accelerator_context" comments that
indicate the contexts of each msgid: the union of all
contexts of all of its uses in the source files. It also
removes any "gettext_accelerator_context" comments that
xgettext --add-comments has copied to elinks.pot.
- If po/gather-accelerator-contexts.pl does not find any
contexts for some use of an msgid that seems to contain an
accelerator (because it contains a tilde), it warns. If the
tilde refers to e.g. "~/.elinks" and does not actually mark
an accelerator, the warning can be silenced by specifying the
special context "IGNORE", which the script otherwise ignores.
- msgmerge copies the "accelerator_context" comments from
po/elinks.pot to po/*.po. Translators do not edit those
comments.
- During make check-po:
- Another Perl script (po/check-accelerator-contexts.pl) reads
po/*.po and keeps track of which accelerators have been bound
in each context. It warns about any conflicts it finds.
This script does not access the C source files; thus it does
not matter if the line numbers in "#:" lines are out of date.
This implementation is not perfect and I am not proposing to
add it to the main source tree at this time. Specifically:
- It introduces compile-time dependencies on Perl and Locale::PO.
There should be a configure-time or compile-time check so that
the new features are skipped if the prerequisites are missing.
- When the scripts include msgstr strings in warnings, they
should transcode them from the charset of the PO file to the
one specified by the user's locale.
- It is not adequately documented (well, except perhaps here).
- po/check-accelerator-contexts.pl reports the same conflict
multiple times if it occurs in multiple contexts.
- The warning messages should include line numbers, so that users
of Emacs could conveniently edit the conflicting part of the PO
file. This is not feasible with the current version of
Locale::PO.
- Locale::PO does not understand #~ lines and spews warnings
about them. There is an ugly hack to hide these warnings.
- Jonas Fonseca suggested the script could propose accelerators
that are still available. This has not been implemented.
There are three files attached:
- po/gather-accelerator-contexts.pl: Augments elinks.pot with
context information.
- po/check-accelerator-contexts.pl: Checks conflicts.
- accelerator-contexts.diff: Makes po/Makefile run the scripts,
and adds special comments to source files.
I changed the %.gmo rule in po/Makefile to use $@ instead of a shell
variable, and made various tweaks in it to better support strange file
names, e.g. spaces in $(srcdir). I suppose other makefiles in ELinks and
other rules in po/Makefile do not support those, but one must start
somewhere. I don't think it will ever be feasible to support backslashes
and quotes without horrible contortions, but spaces and dashes should be
doable.
I also quoted the ~ in --check-accelerators=~ in case some shell might want
to expand it as the home directory. Bash 3.00.16(1) doesn't because the
word contains dashes.
According to the documentation, GNU Make uses them only for suffix rules,
which have been replaced with pattern rules in po/Makefile. The makefiles
included by po/Makefile do not define suffix rules, either.
Involves prefixing with $(srcdir) to some of the build rule variables. For
the builddir we create Makefiles which simply include the srcdir Makefile.
Add list make rule to get list of Makefiles to generate (find will get it
wrong for builddirs nested in srcdir).
There are still a few minor issues like the file paths echoed during make
install ...
Makes it more obvious which files are actually installed. MKINSTALLDIRS
still spurs out a lot of 'mkdir ...', which probably should also be
silenced when V=0.
