7Zip: reposition .sfx file next to executable #25876
Conversation
When using `7z` to make a "Self-extracting" archive the executable
(`7Z.exe` on Windows OSes) when given the command line argument
`-sfx7z*.sfx` expects to find the "extra" code to include in the archive a
file `7z*.sfx` (to provide the test/extraction) functionality to be
alongside the executable in the same directory. The Mingw-w64 project
provides just one of these "modules" - `7zCon.sfx` which provides a basic
"Command line" interface that allows for extraction (default) or testing
(with a `-t` command line argument to the "self-extracting" archive).
However, this (actually an executable programme file) is currently located
in the `{baseDir}/lib/7zip` directory and it is not seen there by the
`7z.exe` exectuable; testing has revealed that moving the file to the
`{baseDir}/bin` directory - so it is in the same directory as the main
application, is sufficient (and is as documentated [here](https://documentation.help/7-Zip/sfx.htm))
to get things to work as expected. Given that the file - though it has a
"weird" `.sfx` extension is identified (by `file`) as a normal executable
(and not a library) it doesn't seem unreasonable to me to relocate it as
this PR sets out to do.
Signed-off-by: Stephen Lyons <[email protected]>
|
As I said on Discord, I'd rather keep the FHS-like structure and modify GetModuleDirPrefix to find the right directory. |
|
To address your arguments:
|
|
I guess an argument is that it never makes sense to invoke 7z.sfx yourself. So it shouldn't be on your PATH. |
|
I'm sorry but I do not believe I have the ability to make modifications upstream to detect that 7Zip is being built in a Mingw-w64 environment and not some other Windows (with
I would note that I can see other "non-executable" files in my By "user-specified" I mean that 7Z supports more than one self-extracting user interface format - the documentation I referred to above lists, says:
Anyhow, by user specified I mean that the end-user could (if they were built) conceivable want to use tl;dr; This PR is a simple one-liner that I can do and will work for me and, I believe others, and not introduce any contradictions with existing (Windows specific maybe?) documentation whereas the possibly technically correct FHS aligned solution is not something I can (currently) grok or do. |
You don't need to do that. You can add patches to the package. |
|
Fair with the -sfx option, I completely missed that it's supposed to be a limited choice. Sorry.
Yes, I don't like them either. To ascend above examples and counter-examples, I note that the goal is to align MSYS2 with FHS, more specifically with modern interpretations of FHS as seen in Arch and an increasing number of other distros. FHS says for both
Fair. It is a practical and easy solution to the issue. I'm just voicing my disagreement and providing arguments for it where needed. Thank you for the willingness and effort regardless of the eventual outcome. |
Actually it is an executable (it is what is run when you "execute" the self-extracting archive) - it is just that run on its own it is not much use! As such it is effectively a "stub" that exists purely to provide test and extraction functions for the archive that it is inserted into. Other |
He chose the word "command" very carefully. He didn't say it wasn't an executable. |
#### Brief overview of PR changes/additions
Revises the Windows OS CI/CB process to:
* Produce a "portable" version of Mudlet for PTBs as well as "Release"
versions
* Exit cleanly earlier in the process for when a PTB is NOT required
{via ABORT_WORKFLOW environmental variable} when no changes to the
`development` branch happened in the last 24 hours.)
* Identify "what" the CI/CB process is being used for once, early on, and
forwarding that to later stages {via BUILD_ACTION environmental variable}.
I.e. adopting a DRY approach!
* Eliminating a couple of environmental variables as they duplicate ones
that MSYS2+Mingw-w64 already provides:
* `"mingw-w64-${BUILDCOMPONENT}"` is the same as `"${MINGW_PACKAGE_PREFIX}`
* `${MINGW_BASE_DIR}` was a Windows (typically `C:/msys64/mingw64`) path
that can be replaced by "${MINGW_PREFIX}" in a POSIX form (typically
`/mingw64`) as far as Qt Creator/`qmake` is concerned.
* Fix a defect in the current `7zip` package which cannot make self-
extracting archives without the "self-extracting" module (`7zCon.sfx`)
being placed alongside the executable (the MINGW-W64 people think it
should be placed in a `./lib/7zip` directory but the executable cannot
see it there - unless it gets patched - which is a bit beyond me whereas
putting it next to the executable isn't:
msys2/MINGW-packages#25876 )!
* Revise some elements of the build naming so that builds that did contain
`-testing-pr####` lose the `-testing` prefix - so that that is ONLY used
for CI/CB builds when a PR is *merged* into the `development` branch.
This should clarify the naming on the web-page that carry the
"snap-shots"!
#### Motivation for adding to Mudlet
Improve end-user experience for those wanting a "Portable" Windows build;
a file that they can run to produce all the files needed for it instead of
having to use a utility (or relying on Windows own zip file handling) to
unzip the archive is simpler. Also,by making the archive a self-extrcting
one it will make it possible to update to a new version by triggering an
older version to run a downloaded copy of a newer one. Furthermore the code
and scripts in this PR should enable the production of "portable" PT Builds
(and PR or "Testing" builds) besides the "Release" only one that the prior
situation was. It also signs the files and the self-extracting archive in
the case of PTB and Release builds which should mean less problems with
anti-virus systems.
#### Other info (issues closed, discussion etc)
This is a necessary prequel to making "portable" PTB and Release builds be
capable of being updated. With the prior scripts only configure to produce
a portable build for "Release" type builds - and there not having been one
of those since the changes for portable builds were put in place the usage
of such a "portable" mode of operation may not have been as extensively
tested as we might like; hopefully this PR will help to change that!
Signed-off-by: Stephen Lyons <[email protected]>
3 participants
When using
7zto make a "Self-extracting" archive the executable (7Z.exeon Windows OSes) when given the command line argument-sfx7z*.sfxexpects to find the "extra" code to include in the archive a file7z*.sfx(to provide the test/extraction) functionality to be alongside the executable in the same directory. The Mingw-w64 project provides just one of these "modules" -7zCon.sfxwhich provides a basic "Command line" interface that allows for extraction (default) or testing (with a-tcommand line argument to the "self-extracting" archive).However, this (actually an executable programme file) is currently located in the
{baseDir}/lib/7zipdirectory and it is not seen there by the7z.exeexectuable; testing has revealed that moving the file to the{baseDir}/bindirectory - so it is in the same directory as the main application, is sufficient (and is as documentated here) to get things to work as expected. Given that the file - though it has a "weird".sfxextension is identified (byfile) as a normal executable (and not a library) it doesn't seem unreasonable to me to relocate it as this PR sets out to do.