Am 03.03.25 um 16:54 schrieb Mark Thomas:
On 03/03/2025 15:38, Rémy Maucherat wrote:
On Mon, Mar 3, 2025 at 1:45 PM Rémy Maucherat <r...@apache.org> wrote:
On Mon, Mar 3, 2025 at 1:27 PM Mark Thomas <ma...@apache.org> wrote:
On 03/03/2025 10:54, Mark Thomas wrote:
<snip/>
I do like the makensis approach as it is a lot simpler. Wine on Mac has
proven tricky to get working in the past. I can see ythe followuing
options:
1. Remove Wine support. Have ant build makensis to the correct recipe
when on Linux.
So +1 for 1) since I was able to get it to work and verify 11.0.5.
That should mean I can again build the Windows installer properly for
9.0.x.
Excellent.
Ok. I would like it more if using my platform makensis was possible.
That looks to be impossible at the moment. The NSIS installer embeds the
installer version in the installer binary so for repeatable builds we
need to ensure the same version as used by the Windows binary is used.
I will be working trying to get a custom makensis this afternoon.
Looks like you got that working. Excellent.
As it is, Wine suppose is broken, the only way to fix it is to revert
to the way signing was done previously.
If we want to support Wine as well as NSIS then I think revert the
changes to use call backs to sign the uninstaller and the installer
should work. That would mean going back to first building the
uninstaller, then the installer.
2. Add a requirement for a Windows JRE to make a release build and add
it and Ant to the path when calling the NSIS installer via Wine.
-1
No way.
Fine by me. I didn't like the option but presented it for completeness.
3. Have the NSIS installer call Ant directly on Windows and via Linux
when running via wine.
When I run "wine cmd" I get the "Windows" shell, where I can type
commands and see what it is possible to do from there. I think it's
not a good plan.
Having spent a few hours trying to get it to work, I agree with you.
I've had zero success. And my sense is that if I did manage to get it to
work, debugging faulty configurations would be difficult.
I'm going to start looking at 3 and the building makensis part of 1 and
see how far I get.
Thoughts?
Well, the previous way before all of that was working just fine for
me. Other than that, I'll see if I can have 1) work.
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.
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.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
