Post by email@example.com Post by David Froble Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
I'm going to say no. With the exception of software VSI has vetted and feels
will not be a problem.
Having this sort of thing available from the official keepers of VMS
might go a good distance toward getting the VMS-specific changes
included in the upstream versions, which would make things easier for
everyone who wants to use a particular tool, regardless of whether
they want a pre-built version from VSI or if they want to download
the source from the upstream and build it themselves.
That really has nothing to do with getting the VMS-specific changes
included in the upstream versions.
All that is needed in most cases is for someone to submit them to the
upstream in the format that the upstream wants. This can take quite a
bit of time.
In addition, for GNU stuff, the upstream usually wants an agreement on
file with the FSF if the submissions contain significant code.
And the upstream usually wants active feedback and participation in
their forums. If they see no notices in their forums for a platform for
a while, then they usually ping the last known contributors, and if they
do not get a positive answer, the platform is slated for removal.
The Bash upstream is very willing to look at the VMS specific code and
bring it into the upstream. None of the GNV developers had have time to
bring that about.
The GNU Make project is also willing to get changes, and that project
needs a lot of work to get it merged with the GNV Make fork.
It still needs a lot of fixes for its VMS mode. I had all the self
tests working locally, but not merged into the upstream.
They are sitting at https://sourceforge.net/p/gnv/make/ci/default/tree/
It has been about 2 years, so they may now need updates to match the
current GNU Make source.
Post by firstname.lastname@example.org
Having support from VSI for things like free VMS developer licenses
or free access to a VSI-hosted development system would also help, as
one of the reasons that VMS support was removed from various open
source projects was because the upstream maintainers didn't have a
system to build and test on. A VSI-hosted system would also solve the
problem for Itanium, as few open source maintainers are going to go
out and buy an Itanium system.
I have an Jenkins system set up that can build from commits to public
repositories on the Internet. If a GNV developer submits an update to
one of the updated project, the Jenkins system will build it with in 24
The GNV gawk source is actually hosted by the GNU Awk project, so every
time any gawk maintainer commits a patch to the 4.1 stable branch, with
in 24 hours I have a VMS build for it on VAX, Alpha, and IA64.
My ISP prevents me from hosting a server. I have a set up a snapshot
(currently 1 week old) of my Jenkins environment on a free container on
a floating address as an experiment.
It can be reached by following the link at
http://encompasserve.org/~malmberg/vms-jenkins.html (The auto redirect
does not work so click on it)
That container Jenkins crashes occasionally apparently from lack of
memory. My system checks it once an hour and attempts a restart.
Not all things from that beta container provider are working as
advertised. But it is free.
I think that a public live Jenkins dashboard instance, particularly
hosted on VMS Itanium system would be a great publicity tool.
Again Hartmut Becker got a Jenkins web page to display on an Itanium,
which indicates that Jenkins may be working at least well enough to be a