msys2
7Zip: reposition .sfx file next to executable
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) 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.
As I said on Discord, I'd rather keep the FHS-like structure and modify GetModuleDirPrefix to find the right directory. The infrastructure seems to be there, see Update.cpp.
To address your arguments:
- being an executable doesn't automatically mean it's supposed to go into bin/, you can find examples in lib/
- the expectation that "This module must be placed in the same directory as the 7z.exe" even if it's user-specified sounds just wrong (not that the docs are wrong, rather I consider the behavior wrong)
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 _WIN32 defined?) setup and thus detect that any .sfx "module" should be in a different location (than that of the main executable) for this particular Windows OS configuration.
To address your arguments:
- being an executable doesn't automatically mean it's supposed to go into bin/, you can find examples in lib/
- the expectation that "This module must be placed in the same directory as the 7z.exe" even if it's user-specified sounds just wrong (not that the docs are wrong, rather I consider the behavior wrong)
I would note that I can see other "non-executable" files in my {base-directory}/bin - e.g. Qt .debug symbols files; some Qt .manifest files; and ibmmsvc.xml (for whatever purpose).
By "user-specified" I mean that 7Z supports more than one self-extracting user interface format - the documentation I referred to above lists, says:
-sfx{SFX_Module}: Specifies the SFX module that will be combined with the archive. This module must be placed in the same directory as the 7z.exe. If {SFX_Module} is not assigned, 7-Zip will use standard console SFX module 7zCon.sfx.
SFX_Module Description 7z.sfx Windows version. 7zCon.sfx Console version. 7zS.sfx Windows version for installers. 7zSD.sfx Windows version for installers (uses MSVCRT.dll).
Anyhow, by user specified I mean that the end-user could (if they were built) conceivable want to use -sfx7z.sfx or -sfx7zS.sfx instead of -sfx (or -sfx7zCon.sfx) to use the default that is provided by Mingw-w64 so as to provide a different UI to the party who gets the "self-extracting" archive.
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.
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 _WIN32 defined?) setup and thus detect that any .sfx "module" should be in a different location (than that of the main executable) for this particular Windows OS configuration.
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.
I would note that I can see other "non-executable" files in my {base-directory}/bin - e.g. Qt .debug symbols files; some Qt .manifest files; and ibmmsvc.xml (for whatever purpose).
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 /bin/ and /usr/bin/ that it should contain "commands" which the SFX module is not.
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.
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.
FHS says for both /bin/ and /usr/bin/ that it should contain "commands" which the SFX module is not.
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 .sfxs (not seemingly built in the Mingw-w64 environment) provide alternative (and in some cases, more sophisticated) UIs - the "installer" type ones as I understand can be configured (with an additional config.txt file) to run a setup.exe or other file upon decompression as well as presenting a titled dialogue with a prompt (e.g. "Do you wish to install 'Application'?) and a progress indication.
Actually it is an executable
He chose the word "command" very carefully. He didn't say it wasn't an executable.