- [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), not the .rc file which is its input.
- [2023-12-28 07:09:28] <cologic> (I know, kind of repeating my first message,
but this time with specific references/citations to source)
- [2023-12-28 07:11:20] <cologic> SCons appears to know about C and C++
compilers kind of natively, haven't 100% tracked down the nuances of why this
doesn't apply recursively to everything, but it has to ground out somewhere
- [2023-12-28 07:15:24] <cologic> Anyway, considering other approaches. One
constraint is that while Python could easily do the required string
manipulation here to ad-hoc fix this, it's passed within the "shell" or process
execution context as an environment variable, and not one that's allowed to be
changed by SCons scripts. So another approach might be to define another
environment variable which is a function of $SOURCES but with whatever changes
are required, then adjust
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/SConstruct#l366 to
pass that environment variable to xgettext instead of $SOURCES directly.
- [2023-12-28 07:15:59] <cologic> Lots of options, just, which is the least
kludgy, least fragile/delicate, and most maintainable.
- [2023-12-28 07:19:29] <cologic> $SOURCES is the result of
https://github.com/SCons/scons/blob/6cbb718516e47dc0c5c8d0e6dc840d22f81e50cc/SCons/Executor.py#L241-L242
so it's probably possible to call something similar from within SConstruct to
replicate that with some variation, without having to kludge some way of
copying out $SOURCES from that shell environment back into Python.
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2045404
Title:
.pot generation is broken since a recent dcplusplus.rc change
Status in DC++:
Confirmed
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2045404/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~linuxdcpp-team
Post to : linuxdcpp-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~linuxdcpp-team
More help : https://help.launchpad.net/ListHelp
