On Sun, Mar 2, 2025 at 10:20 PM Rainer Jung <rainer.j...@kippdata.de> wrote: > > Am 02.03.25 um 21:00 schrieb Rémy Maucherat: > > On Sun, Mar 2, 2025 at 5:10 PM Rainer Jung <rainer.j...@kippdata.de> wrote: > >> > >> Hi Rémy, > >> > >> Am 02.03.25 um 11:06 schrieb Rémy Maucherat: > >>> On Thu, Feb 13, 2025 at 6:11 PM <ma...@apache.org> wrote: > >>>> @@ -163,6 +157,9 @@ Var ServiceInstallLog > >>>> InstType Minimum > >>>> InstType Full > >>>> > >>>> + !finalize 'ant -f @BASEDIR@/build.xml jsign-installer' > >>>> + !uninstfinalize 'ant -f @BASEDIR@/build.xml > >>>> -Dcodesigning.file_to_sign=%1 jsign-uninstaller' > >>> > >>> This fails for me with Can't recognize xxx as an internal or external > >>> command, or batch script. > >>> I tried a few things without much success so far. > >> > >> First the original nsi script should automatically be run by ant through > >> a filter to generate one without @ template strings. Originally the > >> filter replaced version numbers, but in the new build.xml it also > >> replaces BASEDIR. The resulting file would be the one used by makensis. > >> Maybe it makes sense to check, how those lines look like in your > >> environment in the generated file. > >> > >> The other possible problem could be, that ant is not found via PATH. > >> What is "xxx"? just the full "ant -f ...jsign-installer"? With or > >> without replaced BASEDIR? What is your platform? Maybe we would have to > >> change something on Windows? > > > > IMO it simply does not work. If you run on Wine, then you're inside a > > fake Windows env, not the original platform. So if you try to run the > > "ant" command in there, it might simply fail and there's no way at all > > to do it. It does the same for installer and uninstaller, the issue is > > with running command "ant". > > Hmm, I never tried with wine but at least I checked, that the ant > download for Windows contains a binary named "ant", not just "ant.exe". > > But yes, it would mean wine has to find a windows executable ant and > maybe it is also a problem, that the resolved BUILDDIR does not work > under the wine Windows emulation :(
Another problem is that it seems makensis does not build the same Windows installer (the .dll runtimes in $PLUGINSDIR are different). > > Was this retested with Wine ? It seems the 10.1 tag is bad too so I'm > > likely not the only one having an issue. > > > > Installing makensis worked (installing it was annoying since the > > Fedora packaging was messy - probably it can be installed without > > distro packaging). So if that's "ok", then you should remove the Wine > > support since there are only 2-3 users for this. > > It seems it has to be installed from source. I had added the info from > Mark, how it was build, to the BUILDING.txt. Using this recipe, I could > recreate the TC 11.0.5 installer on my system. > > For 9.0.101 it didn't work, but I do mot yet know, whether this is true > to "your" makensis not having been build with that recipe, or for > instance because the Windows installer contains some of the Javadoc > pages that my Java/Filesystem always generates different from the ones > others get. But since my generated exe and the one in the release vote > differ by about 140KB in size, I guess it is not only Javadocs > differences, but also makensis binary differences. Yes, ok, I did not use your recipe since I had not seen it. I tried Wine, which failed. I thought this was tested, apparently not. I moved on to makensis after a while. Since Fedora had a package, I simply used that. The package was imperfect (some dependency had to be added manually), but it worked. Guess it does not follow the recipe, so the installer generated is different. The problem is that I do not understand the recipe. Rémy > Best regards, > > Rainer > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
