Mark,
On 3/3/25 1:08 PM, Mark Thomas wrote:
On 03/03/2025 16:08, Rainer Jung wrote:
Am 03.03.25 um 16:54 schrieb Mark Thomas:
<snip/>
So, I think we have a different set of options now:
a) Keep the existing makensis approach and remove Wine support
b) Revert the change to using callbacks to sign the uninstaller and
installer. Keep the option for makensis or wine.
The need for the call-backs has arisen from supporting non-Windows,
non- wine. Previously we built a temporary installer in form of a
Windows exe. Then executed this temporary installer to get the
uninstaller and then finally built the installer. The step of
executing the temporary installer was only possible on Windows or
wine. So IMHO b) means no longer supporting natively build the Windows
installer on non-Windows without wine.
c) Revert all the changes and go back to wine.
I think b) and c) are the same for the reasons given above.
Good point. Both b) & c) need wine.
and a bonus option d) that is an addition to a) or b):
d) Try and build a local makensis as part of the build script
I'm not sure I see the value in maintaining support for makensis and
wine. I'm prepared to be convinced if someone can see a reason.
Otherwise I prefer a). I'm happy to try and get d) to work if a) (or
b)) is the agreed way forwards.
I prefer a), but I am not an RM. Option d) might work, but some
prerequisites are of course needed, like a compiler toolchain
supported by the SConstruct and maybe a python and scons installation.
I don't think we want to do this from the ant build. Downloading the
correct nsis source and running the scons command would be possible
and inside the ant build we have all the subtle points, like which
version, which prefix in our hands.
I have this working in the Ant build. I could move this to an
independent set of targets so folks can build makensis manually or via
Ant. What do folks think?
How stable is NSIS? I know we've upgraded the version over time... the
last upgrade was 2024-04-29, less than a year ago. If/when NSIS 3.11
comes out, I'm very unlikely to notice a small commit that increments
that version number and I'll probably use my old makensis local build.
Whether we add an ant target to build makensis or not, I think the
primary build needs to make sure the build is using the expected version
of the tool.
I don't mind another target to run periodically, but I'd like ant to
tell me I need to do it if it's not going to do it by itself.
I'm also planning on removing Wine support unless there are objections.
No real objection here.
The old release artifacts include information for how to reproduce the
build in BUILDING.TXT (though they are a little vague... I may try to
improve them), so removing all that stuff from BUILDING.txt and the
Release Process wiki would be good. I'm happy to do that work once we
have removed Wine support from git.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
