Thus spake Flint1b:
I spent some time trying to wrestle the current parts of the makefile
that build the various releases into maven. It looks like it could work,
but it’s too much hassle, the end result is too verbose, it’s like
walking on crutches. Right now my idea is to throw all these experiments
away and try using Java 14’s jpackage. Travis offers linux, windows and
macos machines, the requirements for jpackage can be installed
theoretically.
I doubt that you will get jpackage to work for building all the packages
on a single host, for the following reason: When I tried jpackage, I found
that the Windows-specific parts work only on Windows, the Mac-specific
parts only on Macs.
But some questions came up while I was doing this:
- the “other” release contains both a bash script and the exe for
windows, what is it for exactly? Windows users will most likely not
download it at all, linux and mac users would also download the releases
for their respective systems, is the “other” release for some obscure
niche unixes like freebsd?
The “other” package is intended for the case where none of the others
work for you. That could be because you’re on some other Unix (though
in that case, it’s likely that the Linux package would work as well),
or it could be because you’re on Windows but can’t install anything,
or you want to run from a USB drive.
- the linux (and other) release come without installers, while the
windows and macos come with installers, why is this not symmetrical? As
a linux user I am glad I can just unzip several versions of Vassal next
to each other and select the one I want to run, and select the Java
version I want to run it with, but are Windows/Mac users not at a
disadvantage here because they need to use the installer or can they
install several versions of Vassal as well?
- Bundling Java on Linux is the Wrong Thing. Java’s libjvm dynamically
links to various other libraries (e.g., libstdc++, libm, libc, libgcc)
and all these libraries have versioned symbols. So, if you supply a
libjvm that you want to be sure will work for the user, it has to be
compiled and linked against libraries which are no newer than the ones
the user has… which it turns out is a VERY broad range when you start
considering Long Term Support releases that a lot of distros do. I checked
one of the few projects that bundles Java for Linux and found that they
have a libjvm which is compiled against a libc which was released more
than a decade ago… This is not a good road to go down.
Any Linux user is a single command away from having a version of Java
which works with VASSAL. The Right Thing on Linux is to take advantage of
the nice, mature package management that every distro has and use the
build of Java the distro maintainers have ensured will work for the
distro the user is running.
- The Windows installer gives you some options for how to install VASSAL.
The “Standard” install uninstalls older versions and puts VASSAL X.Y.Z into
C:\Program Files\VASSAL-X.Y.Z. The “Custom” install lets you choose which
older versions to remove and which to keep, and also lets you choose a
different install path if you want. There’s nothing preventing you from
having several versions of VASSAL installed simultaneously.
The pre-3.3 Windows installer also checked for Java and installed Java
for you if you didn’t have it, before a change at java.com broke that.
Before the Windows installer, we had endless problems with Windows users
(a) being confused when VASSAL wouldn’t run because they didn’t have
Java installed, (b) having a screwed up Java installation, (c) not knowing
how to “install” from a ZIP archive. In general, having an installer is
a normal thing on Windows, and not having one was considered weird.
*The Mac app bundle has the version as part of its name, so if you install
two different versions, they’ll end up in different directories, so there’s
nothing preventing you from having multiple versions of VASSAL installed
on a Mac, either.
- the makefile’s “module_deps” target, what is the “grep -v split
package” for, it seems to not do anything since the output of jdeps is
only a single line which only contains the jmods?
That was to filter out something which no longer shows up in the output,
I think since we eliminated the --add-exports. I’m removing it now.
And the "tr -d ‘\n’,
is it necessary? I have not tried it myself but I have seen several
examples of this jdeps-jlink chain where the output of jdeps is fed into
jlink without grepping and removing newlines, in one case they even put
this output into a $VAR and passed it to jlink.
That’s also no longer needed. (Possibly I was wrong that it was ever
needed, but it didn’t harm anything.) It’s removed in PR 51.
- the license is Lesser GPL 2.1, I have never dealt with these things
before, does it have to stay at 2.1 or can it be updated to the newer
3.0 just like that, without consulting a lawyer?
IIRC, there’s an “any later version” provision, but I would need to
check on that to be sure.
Also, big respect to those who do 1st level support, I have watched the
“bug” reports and other questions and I understand much better now why
the users are spoon-fed with installers and bundled JREs…
Are there T-shirts which say “USERS ARE WHY I DRINK” on them?
–
J.