Il file VERSION dice 2.3.1, rilasciata da e0dc59b il 2026-05-05: il
consolidamento in 2.3.0 (bc02b8b) e' storia, due giorni dopo la 2.3.1 e'
stata rilasciata davvero.
«Ultimo commit funzionale f4cd9b9 (03/05), da allora un solo commit di
manutenzione» era falso: il 17/05 ci sono sette commit sul sistema di build
(--dist, build parallele, vswhere per VS2026), l'ultimo applicativo e'
b12a8b4. Dopo, solo documentazione e manutenzione fino al 22/08.
Trovato il 2026-09-12 scrivendo le Fondamenta della nota wiki.
Sostituzione meccanica dei segnali, nessun cambio di contenuto:
- ⚠️ → 🚨 e 🧊 → ⏸️, scelte di Simone il 2026-08-24
- ⛔/🛑 → ❌ e 📌 → ℹ️, ritirati dalla spec del 2026-08-22
- ❌ seguito da U+FE0F, se no il font di testo lo rende come una × sottile
Fatta con wiki/bin/cambia-segnale.py e wiki/bin/fix-emoji-fe0f.py, che saltano
blocchi di codice, span fra backtick e symlink, e non muovono il mtime.
Vocabolario: wiki/docs/specs/2026-08-22-segnali-e-colori.md
I link andavano a 7zip-19.00/, 7zip-25.01/, 7zip-26.00/: nomi ereditati
dal monorepo di partenza e mai esistiti qui. Le versioni stanno in
versions/, submodule popolati (git submodule status) con il loro
README.md. Corretti README.md e README_IT.md.
Chiude la voce di W8 in _wiki/TODO.md: il README non aveva una sezione STATO, che
e' anche quella da cui wiki-sync ricava la sintesi nella nota di progetto.
dist/ already tracks the pre-built DLLs, so a packaged
nsis-plugin-ns7zip-<version>-<arch>-<charset>.zip in the root is a build
product: it only made `git status` dirty.
Print a timing summary (each config status+seconds and total wall
clock) for both parallel and sequential paths, mirroring the Windows
build output. Helps compare Linux vs Windows and track perf changes.
Two 18.x installs coexisted: VS2026 Community (full IDE, has VC v180)
and a BuildTools at (x86)\Microsoft Visual Studio\18\BuildTools that
has MSBuild but NO VC v180 targets. The vswhere query only required
Microsoft.Component.MSBuild, so -latest could (and did) return the
C++-less BuildTools -> MSB4019. Also require
Microsoft.VisualStudio.Component.VC.Tools.x86.x64 so only installs
with the C++ toolset match; the broken BuildTools is excluded and
2026\Community is selected. CI VM BuildTools has the C++ workload so
it still matches.
VS2026 ships on the prerelease channel; vswhere omits it unless
-prerelease is given. Without it _find_msbuild_via_vswhere returned
nothing, so the path fallback picked an incomplete
(x86)\Microsoft Visual Studio\18\BuildTools install (MSBuild present
but no VC v180 targets) -> MSB4019 on hosts that have VS2026 IDE but
not BuildTools. -prerelease is harmless on the CI VM (BuildTools is
found regardless).
Splitting make -j across configs (jobs // nconfigs) made each parallel
config single-threaded on a 4-vCPU VM, so 3 concurrent serial builds
were as slow as the old sequential path (~7min). Windows (MSBuild)
runs the 3 configs in parallel each using all cores and finishes in
~2min on the same vCPU/RAM. Mirror that: give every parallel config
the full make -j; the scheduler absorbs the mild oversubscription.
Linux built the 3 configs sequentially (~3x a single config); Windows
already parallelizes. Run them concurrently via ThreadPoolExecutor,
splitting make -j across configs to avoid CPU oversubscription.
Symlink setup serialized with a lock. --no-parallel restores
sequential. Brings Linux wall time close to Windows.
Same --dist redirect (output to <repo>/dist/<config> instead of
plugins/<config>) applied to every per-version Windows script so the
flag works regardless of --7zip-version/--toolset the dispatcher
selects. Mirrors build_plugin_2601_vs2026.py + the Linux path.
When --dist is passed (forwarded by build_plugin.py to the per-version
script), built nsis7z.dll files are copied to <repo>/dist/<config>
instead of <repo>/plugins/<config>. Lets CI collect a clean dist/
tree without touching the committed plugins/ dir. Windows
(2601_vs2026) and Linux build paths both supported.
All 6 case-sensitivity shim headers in tools/linux/overlay/include/
now use #include_next instead of #include to forward to the real
MinGW system header, avoiding infinite preprocessor recursion on
Linux (Debian/WSL) where overlay/include is first in the search path.
Fixes build failures on Debian WSL (GCC 12) for all configurations.
Also update nsis7z.dll binaries built with the fixed overlay.
Bundle source files (Main.cpp, ExtractCallbackConsole.cpp, MainAr.cpp,
StdAfx.h) use relative #includes like ../../../Common/ and ../../IPassword.h
that work on Linux via POSIX symlinks but fail on Windows where no symlinks
exist in the bundle tree.
Adding versions/VER/CPP/7zip/UI/Common/ as an AdditionalIncludeDirectory
makes MSVC resolve the ../ segments correctly against that anchor directory,
reaching the vendor files without requiring symlinks.
Fixes all three bundles: 25.01, 26.00, 26.01.
The script was used once (commit 2207fbf) to rewrite vcxproj paths from
symlink-dependent relative paths to direct vendor submodule paths.
All bundle vcxproj files are already updated; the script has no further use.
setup_bundle_symlinks.py creates POSIX symlinks inside versions/*-bundle/
at build time on Linux. These must not be committed to git (they break
Windows clones) but were appearing as untracked (??) entries in git status.
Add precise gitignore patterns that cover all generated symlink paths
(C, Asm, CPP/*.mak, CPP/7zip/*.mak|.h|.rc, CPP/7zip/Archive|Common|...,
CPP/7zip/UI/Agent|Console|...) without hiding the tracked project-owned
sources in Bundles/Nsis7z/ and UI/NSIS/.
Aligns the zstd NSIS wrapper directory with the naming convention used by
all other bundle directories (versions/25.01-bundle, 26.00-bundle, etc.).
Changes:
- git mv versions/zstd -> versions/zstd-bundle (20 project-owned files)
- Fix UI/NSIS/StdAfx.h: use relative include ../../Bundles/Nsis7z/pluginapi.h
instead of absolute-style 7zip/Bundles/Nsis7z/pluginapi.h (portable across
both Linux and Windows builds without extra include path)
Build tool updates:
- tools/legacy/build_plugin_zstd_vs2026.py: updated project_dir path
- tools/linux/build_plugin_linux.py:
* VERSION_LAYOUT zstd: zstd -> zstd-bundle
* VERSION_EXTRA_FLAGS zstd: -Wno-sign-compare -Wno-cast-function-type
(fast-lzma2 C vendor code)
* VERSION_EXTRA_CXXFLAGS zstd: -Wno-unused-parameter (NSIS wrapper)
* EXTRA_SYS_OBJS: inject MyWindows.o for zstd (LocalFileTimeToFileTime2)
* Remove 'zip_version != zstd' exception; auto-recreate symlinks for all
bundle versions including zstd
- tools/linux/setup_bundle_symlinks.py: add VENDOR_DIR mapping so 'zstd'
points to versions/7-zip-zstd (not versions/zstd which no longer exists)
- tools/linux/overlay/makefile.gcc: add EXTRA_SYS_OBJS ?= variable so
callers can inject additional objects without modifying the file
Linux build status after this commit:
python3 build_plugin.py --7zip-version zstd -> Build completed (all 3 configs)
After the previous commit removed symlinks from git (they break Windows
clones), a fresh Linux clone or git checkout would leave the bundle
directories without the POSIX symlinks that the GNU make build needs.
Add _ensure_bundle_symlinks() to build_plugin_linux.py: before the first
make invocation for a bundle-based version it checks whether the bundle
root symlink (bundle/C -> ../VER/C) exists and, if not, runs
setup_bundle_symlinks.py automatically so the developer never has to
run the setup script manually.
Windows builds now use direct relative paths to the vendor submodules
(same pattern as versions/zstd bundle) instead of relying on POSIX
symlinks that git cannot materialise correctly on Windows without
Developer Mode / core.symlinks=true.
Changes:
- Remove all 66 symlinks from each of 25.01-bundle, 26.00-bundle,
26.01-bundle (198 total). POSIX symlinks are still created on Linux
by setup_bundle_symlinks.py for the GNU make builds.
- Update Nsis7z.vcxproj / Nsis7z_vs2026.vcxproj in all three bundles:
depth-4 ..\..\..\..\C\ -> ..\..\..\..\..\VER\C depth-3 ..\..\..\{Common,Windows}\ -> ..\..\..\..\..\VER\CPP\{...} depth-2 (non-NSIS) -> ..\..\..\..\..\VER\CPP\7zip\...
UI\NSIS paths unchanged (real bundle files)
AdditionalIncludeDirectories patched to point at vendor CPP/
- Add tools/fix_bundle_vcxproj_paths.py (idempotent helper used to
perform the rewrite; kept for future reference / re-runs)
The three per-version setup_*_bundle_symlinks.py scripts were logically
identical, differing only in the version string. Replace the duplicated
logic with a single parameterised script:
tools/linux/setup_bundle_symlinks.py <version>
The three named scripts are kept as one-liner thin wrappers that forward
to the unified script, preserving backwards compatibility.
- tools/linux/build_plugin_linux.py: point VERSION_LAYOUT['25.01'].bundle_dir
to versions/25.01-bundle/; update comment (all versions now use bundle dirs).
- tools/legacy/build_plugin_2501_vs2026.py: point project_dir to 25.01-bundle/.
- tools/legacy/build_plugin_2501_vs2022.py: point project_dir to 25.01-bundle/.
Remove the ~1316 vendor source files committed under versions/25.01/ and
replace them with a git submodule pointing to ip7z/7zip tag 25.01
(SHA 5e96a82). Project-owned build files move to versions/25.01-bundle/
(next commit).
- tools/linux/build_plugin_linux.py: point VERSION_LAYOUT['26.00'].bundle_dir
to versions/26.00-bundle/ (was versions/26.00/); update module docstring.
- tools/legacy/build_plugin_2600_vs2026.py: point project_dir to
versions/26.00-bundle/ (was versions/26.00/).
- tools/linux/setup_26_01_bundle_symlinks.py: refactor to use bundle_root /
vendor_root variables and add C/Asm root-level symlink creation, matching
the new setup_26_00_bundle_symlinks.py convention.
Mirror the 26.01-bundle approach for 26.00:
- versions/26.00-bundle/CPP/7zip/Bundles/Nsis7z/: project-owned NSIS plugin
wrapper sources (api.h, nsis7z.cpp, pluginapi.*, resource.*, StdAfx*,
Nsis7z.sln, Nsis7z.vcxproj, Nsis7z.vcxproj.filters, Nsis7z_vs2026.vcxproj).
- versions/26.00-bundle/CPP/7zip/UI/NSIS/: NSIS UI sources (Main.cpp,
ExtractCallbackConsole.*, NSISBreak.*, UserInputUtils2.*, StdAfx.h).
- versions/26.00-bundle/CPP/7zip/LzmaDec_gcc.mak: forwarding stub so that
the CWD-relative `include ../../LzmaDec_gcc.mak` in Arc_gcc.mak resolves
correctly when make runs from the Nsis7z bundle dir.
- versions/26.00-bundle/{C,Asm} and CPP sub-trees: symlinks into versions/26.00/
so the vendor headers and sources are visible without modifying the submodule.
- tools/linux/setup_26_00_bundle_symlinks.py: idempotent script to recreate
all symlinks after a fresh clone + submodule initialisation.
Remove the ~1315 vendor source files committed under versions/26.00/ and
replace them with a git submodule pointing to ip7z/7zip tag 26.00
(SHA 839151e). The upstream 26.00 tag does not ship a Nsis7z bundle, so
all project-owned build files live in the separate versions/26.00-bundle/
directory (added in the next commit).
Cross-compiled from Linux using MinGW-w64 via the new overlay build
infrastructure. All three targets built clean (Exit Code 0):
- plugins/x86-ansi/nsis7z.dll (i686, non-unicode)
- plugins/x86-unicode/nsis7z.dll (i686, unicode)
- plugins/amd64-unicode/nsis7z.dll (x86_64, unicode)
- Add tools/legacy/build_plugin_2601_vs2026.py: Windows build script for
7-zip 26.01 using VS2026 toolset (v145), adapted from the zstd equivalent.
Points to versions/26.01-bundle/ as the project root.
- Update build_plugin.py:
- Add LINUX_SCRIPT reference to tools/linux/build_plugin_linux.py.
- Add '26.01' to WINDOWS_SCRIPTS with v2026 entry pointing to the new
script (v2022 remains None; 26.01 requires v145 minimum).
- Add '26.01' to LINUX_SUPPORTED_7ZIP set.
- Add '26.01' to argparse choices.
Simone
github-actions[bot]