On Thu, May 19, 2022 at 5:53 PM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> In the previous discussion of kicking things around I lost track of what
> version of mine this is picked up from, but I range-diff'd it to my
> 6cf9c1f7022 (Makefile: have "make pot" not "reset --hard", 2022-04-02),
> which is the latest I had in avar/Makefile-incremental-po-git-pot-rule
> on my branch.
>
> A range-diff of the two follows below (yours being the RHS). Some
> comments:
>
> * There's a bug here where you're creating .build/pot/po/pretty.c.po
> files, not .build/pot/po/pretty.c, i.e. you add a *.po extension.
In the original version of your commit, each source file has a
duplicate version in the ".build/" directory, and this will confuse
IDE (E.g.: VS Code) when I jump to a function declaration.
Name the "pot" snippets with the ".po" extension only have the
following side effect, nothing else:
+#. #-#-#-#-# add-patch.c.po #-#-#-#-#
#. TRANSLATORS: do not translate [y/n]
[...]
+#. #-#-#-#-# git-add--interactive.perl.po #-#-#-#-#
I add some notes in commit message:
While we could rename the "pot" snippets without the ".po" extension
to use more intuitive filenames in the comments, but that will
confuse the IDE with lots of invalid C or perl source files in
".build/pot/po" directory.
> * We went a bit back & forth on the "if grep -q PRItime" part on the GH
> ticket. FWIW I still think just skipping that work is a better
> choice. Yes we'll have ~10MB of redundant files in .build, and it's
Redundant source files (*.c, *.h, *.perl) in .build will make IDE mad.
> marginally slower, but "make pot" isn't a hot target, better to
> optimize for simplicity.
>
> But if you're really set on having it I don't mind...
>
> * You add a "MSGCAT_FLAGS = --sort-by-file" here, maybe worth having
> some "common" flags variable in the earlier commit we can use here?
> I.e. share --sort-by-file with xgettext.
>
> * Your version is missing FORCE on po/git.pot, which is a bug. We can't
> omit it on any file that's checked in. We're about to "git rm" it
> anyway, so maybe we shouldn't worry about it though...
I'm confused. Since the "po/git.pot" target has a full set of
prerequisites, it is fine to remove FORCE from dependence.
