.pot generation is broken since a recent dcplusplus.rc change

[eMTee]

An item is needed to remove from $SOURCES used in https://sourceforge.net/p/dcplusplus/code/ci/7cfc388170e408c621aa100f8f3563815f46566d/tree/SConstruct#l359 and on for "Extracting messages to $TARGET from $SOURCES".
$SOURCES is a list of files to build and supposedly coming directly from SCons, a list of .h and .cpp files reside in dcpp and win32 folders with the exception of DCPlusPlus.o (DCPlusPlus.rc's generated object file). This action where $SOURCES passed as a parameter actually gets the strings from source files in dcpp and win32 for .pot generation.
I don't know how it worked before, maybe it's something caused by a change in Scons versions along the way that this .o file (and not the .rc one) is in the list. Or maybe it has been like that always so the .o file has been left on the list, as supposedly there's no strings with the gettext syntax to be found in an .o file.
Until now. Since .rc has changed recently with the new icons, gettext finds one item, a garbage string with zeros and whatever multibyte contents in the .o file and makes one garbage item in the .pot file coming from DCPlusPlus.o.
This rogue string then appears in the transalting interface but more annoyingly breaks the .po/.mo generation as well and has to be removed by hand when the build of the distro stops with an error.

[eMTee (realprogger)]

- [2023-12-28 06:51:22] <cologic> regarding the .pot generation, the basic reason is that because of the windres .rc to .o step being defined as a separate Action/Builder (presumably the same issue would apply with slight variations with the MSVC tooling under SCons -- the important part is that it's a separate/subsidiary/implied Builder/Action which triggers on *.rc files), the main consolidated build step in win32/ with all the .cpp files automatically invokes this windres Builder/Action and then treats the resulting .o (maybe different suffix for MSVC tools, but should be same issue) as a "source" for the overall dev.build('win32/') step
- [2023-12-28 06:58:21] <cologic> SCons $SOURCE isn't necessarily source files as such, but e.g., basically the same thing happens with all the other subsidiary builds (dev.zlib = dev.build('zlib/'), dev.geoip = dev.build('geoip/'), dev.miniupnpc = dev.build('miniupnpc/'), dev.natpmp = dev.build('natpmp/'), dev.client = dev.build('dcpp/'), etc) where they go through two SOURCE -> TARGET steps, the only the first of which actually has the "source file" .cpp in $SOURCES. By the time the main build happens, the source, as far as SCons is concerned, is the .o or .a file resulting from that subsidiary build. But because of how the xgettext invocation is set up, this .rc file being in the win32/ directory of that main dev.build('win32/') step means that because SCons views it as an implicitly two-step build through this custom Action/Builder, by the time xgettext runs, that .rc to .o transformation has already occurred and is hidden behind the SCons/Tool/mingw res_action/res_builder action abstraction.
- [2023-12-28 07:00:05] <cologic> This is testing with SCons 4.5.2, in https://packages.debian.org/sid/scons and https://packages.debian.org/trixie/scons
- [2023-12-28 07:04:36] <cologic> I'm not sure why it might have done something else before, but could imagine various reasons if it wasn't a quirk as you noted. In any case, this doesn't appear to be a bug as such, but a consequence of the general-purpose design of SCons's SOURCE and TARGET definitions, where $SOURCES is just the input files and $TARGETS is just the output files of each step, which can take other steps as input, and therefore $SOURCES doesn't necessarily contain source files. My inclination is to say the xgettext invocation using $SOURCES might be wrong, but another approach, if the .rc doesn't have to be localized itself, might be to move it out of win32/ if that's feasible/otherwise reasonable, which I've not checked
- [2023-12-28 07:06:54] <cologic> https://github.com/SCons/scons/blob/6cbb718516e47dc0c5c8d0e6dc840d22f81e50cc/SCons/Tool/mingw.py#L122-L126 is where SCons defines this resource compilation implicit builder/action for mingw and https://github.com/SCons/scons/blob/6cbb718516e47dc0c5c8d0e6dc840d22f81e50cc/SCons/Tool/msvc.py#L155-L162 defines it for MS VC.
- [2023-12-28 07:08:59] <cologic> The issue is that the dev.build('win32/') step at https://sourceforge.net/p/dcplusplus/code/ci/default/tree/SConstruct#l444, which defines the context in which that xgettext runs, sees the output of that res_action/res_builder (the .o for mingw), n...

[eMTee (realprogger)]

<cologic> this should work:

diff -r 16df2b91f3a6 SConstruct
--- a/SConstruct Mon Nov 06 12:03:32 2023 +0100
+++ b/SConstruct Thu Dec 28 22:19:56 2023 +0000
@@ -363,7 +363,7 @@
     '--no-wrap', '--keyword=_', '--keyword=T_', '--keyword=TF_',
     '--keyword=TFN_:1,2', '--keyword=F_', '--keyword=gettext_noop',
     '--keyword=N_', '--keyword=CT_', '--boost', '-s', '--output=$TARGET',
- '$SOURCES'
+ '${list(filter(lambda _: not str(_).endswith(".o"), SOURCES))}'
 ]
 pot_bld = Builder(action=Action(
     [pot_args],

<cologic> https://scons.org/doc/4.0.0/HTML/scons-man.html#python_code_substitution