Makefile: have "make pot" not "reset --hard"

Before commit fc0fd5b23b (Makefile: help gettext tools to cope with our custom PRItime format, 2017-07-20), we'd consider source files as-is with gettext, but because we need to understand PRItime in the same way that gettext itself understands PRIuMAX, we'd first check if we had a clean checkout, then munge all of the processed files in-place with "sed", generate "po/git.pot", and then finally "reset --hard" to undo our changes. By generating "pot" snippets in ".build/pot/po" for each source file and rewriting certain source files with PRItime macros to temporary files in ".build/pot/po", we can avoid running "make pot" by altering files in place and doing a "reset --hard" afterwards. This speed of "make pot" is slower than before on an initial run, because we run "xgettext" many times (once per source file), but it can be boosted by parallelization. It is *much* faster for incremental runs, and will allow us to implement related targets in subsequent commits. When the "pot" target was originally added in cd5513a7168 (i18n: Makefile: "pot" target to extract messages marked for translation, 2011-02-22) it behaved like a "normal" target. I.e. we'd skip the re-generation of the po/git.pot if nothing had to be done. Then after po/git.pot was checked in in dce37b66fb0 (l10n: initial git.pot for 1.7.10 upcoming release, 2012-02-13) the target was broken until 1f31963e921 (i18n: treat "make pot" as an explicitly-invoked target, 2014-08-22) when it was made to depend on "FORCE". I.e. the Makefile's dependency resolution inherently can't handle incremental building when the target file may be updated by git (or something else external to "make"). But this case no longer applies, so FORCE is no longer needed. That out of the way, the main logic change here is getting rid of the "reset --hard": We'll generate intermediate ".build/pot/po/%.po" files from "%", which is handy to see at a glance what strings (if any) in a given file are marked for translation: $ make .build/pot/po/pretty.c.po [...] $ cat .build/pot/po/pretty.c.po #: pretty.c:1051 msgid "unable to parse --pretty format" msgstr "" $ For these C source files which contain the PRItime macros, we will create temporary munged "*.c" files in a tree in ".build/pot/po" corresponding to our source tree, and have "xgettext" consider those. The rule needs to be careful to "(cd .build/pot/po && ...)", because otherwise the comments in the po/git.pot file wouldn't refer to the correct source locations (they'd be prefixed with ".build/pot/po"). These temporary munged "*.c” files will be removed immediately after the corresponding po files are generated, because some development tools cannot ignore the duplicate source files in the ".build" directory according to the ".gitignore" file, and that may cause trouble. The output of the generated po/git.pot file is changed in one minor way: Because we're using msgcat(1) instead of xgettext(1) to concatenate the output we'll now disambiguate where "TRANSLATORS" comments come from, in cases where a message is the same in N files, and either only one has a "TRANSLATORS" comment, or they're different. E.g. for the "Your edited hunk[...]" message we'll now apply this change (comment content elided): +#. #-#-#-#-# add-patch.c.po #-#-#-#-# #. TRANSLATORS: do not translate [y/n] [...] +#. #-#-#-#-# git-add--interactive.perl.po #-#-#-#-# #. TRANSLATORS: do not translate [y/n] [...] #: add-patch.c:1253 git-add--interactive.perl:1244 msgid "" "Your edited hunk does not apply. Edit again (saying \"no\" discards!) [y/n]? " msgstr "" There are six such changes, and they all make the context more understandable, as msgcat(1) is better at handling these edge cases than xgettext(1)'s previously used "--join-existing" flag. But filenames in the above disambiguation lines of extracted-comments have an extra ".po" extension compared to the filenames at the file locations. While we could rename the intermediate ".build/pot/po/%.po" files without the ".po" extension to use more intuitive filenames in the disambiguation lines of extracted-comments, but that will confuse developer tools with lots of invalid C or other source files in ".build/pot/po" directory. The addition of "--omit-header" option for xgettext makes the "pot" snippets in ".build/pot/po/*.po" smaller. But as we'll see in a subsequent commit this header behavior has been hiding an encoding-related bug from us, so let's carry it forward instead of re-generating it with xgettext(1). The "po/git.pot" file should have a header entry, because a proper header entry will increase the speed of creating a new po file using msginit and set a proper "POT-Creation-Date:" field in the header entry of a "po/XX.po" file. We use xgettext to generate a separate header file at ".build/pot/git.header" from "/dev/null", and use this header to assemble "po/git.pot". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>