linuxdcpp-team team mailing list archive

[eMTee <2045404@xxxxxxxxxxxxxxxxxx>]

- [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