fix: #225 endgame follow-ups — EC codegen tag sync + po LF line endings - #333
Merged
got3nks merged 2 commits intoJul 6, 2026
Merged
Conversation
PR amule-project#225 added EC_TAG_FILES_ENDGAME (0x1810) to the generated src/libs/ec/cpp/ECCodes.h but not to its generator source src/libs/ec/abstracts/ECCodes.abstract (nor the ECCodes.java binding). Clean builds that regenerate the header from the abstract — as the Flatpak CI does — drop the tag, so amulecmd (TextClient.cpp) and ECSpecialMuleTags.cpp fail to compile with "EC_TAG_FILES_ENDGAME was not declared in this scope". AppImage and the standard builds compile the committed header and stay green, which is why only Flatpak broke. Add the tag to both generator sources so the regenerated and committed headers agree in every build configuration.
…roject#225 amule-project#225 (c844cb9) was committed from a CRLF environment (core.autocrlf), flipping 12 gettext infrastructure/skeleton files to CRLF with no content change: CMakeLists.txt, LINGUAS, Makevars, POTFILES.in, Rules-quot, boldquot.sed, quot.sed, [email protected], [email protected], insert-header.sin, remove-potcdate.sin, l10n.xsl. Renormalize them back to LF and add a `po/** text=auto eol=lf` .gitattributes rule so a Windows / autocrlf checkout can't reintroduce it. The .po/.pot catalogs themselves stayed LF and are untouched here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two follow-up fixes for the endgame-mode PR (#225), both cleaning up collateral unrelated to the feature itself.
1.
EC_TAG_FILES_ENDGAMEmissing from the EC generator sources#225 added
EC_TAG_FILES_ENDGAME(0x1810) to the generatedsrc/libs/ec/cpp/ECCodes.hbut not to its generator sourcesrc/libs/ec/abstracts/ECCodes.abstract(nor theECCodes.javabinding). Builds that regenerate the header from the abstract — which the Flatpak CI does — drop the tag, soamulecmd(TextClient.cpp) andECSpecialMuleTags.cppfail withEC_TAG_FILES_ENDGAME was not declared in this scope. AppImage and the standard builds compile the committed header and stayed green, which is why only Flatpak broke. Added the tag to both generator sources so the regenerated and committed headers agree in every configuration.2. gettext infra files flipped to CRLF
#225 was committed from a CRLF environment (
core.autocrlf), flipping 12 gettext infrastructure/skeleton files to CRLF with no content change:LINGUAS,Makevars,Rules-quot,POTFILES.in,CMakeLists.txt,boldquot.sed,quot.sed,[email protected],[email protected],insert-header.sin,remove-potcdate.sin,l10n.xsl. Renormalized them back to LF and added apo/** text=auto eol=lfrule to.gitattributesso an autocrlf checkout can't reintroduce it. The.po/.potcatalogs themselves were already LF and are untouched.