[Info-vax] OpenVMS development tooling (was: Re: VSI strategy for OpenVMS)

[Stephen Hoffman]

On 2021-09-28 02:18:57 +0000, Lawrence D’Oliveiro said:

> On Tuesday, September 28, 2021 at 4:50:56 AM UTC+13, Stephen Hoffman wrote:
>> macOS has the open-source project homebrew, which pulls in some fairly 
>> complex> recipes with many dependencies, and it typically all just 
>> builds.
> 
> Unfortunately, trying to do package management via a third party is 
> always going to be problematic, particularly on a proprietary platform. 
> Too much chance of the platform owner simply clobbering your addon 
> installation with its own little organizational changes in some minor 
> update.

If you're following the traditional Linux and the equally traditional 
OpenVMS approaches here toward mixing it all together, sure. For other 
platforms, this all gets rather easier. This all being omissions I've 
been grumbling about in various threads.

> And how do you do things like, say, install a newer version of Python, 
> without breaking platform-specific tools that rely on an older version?

Some platforms (previously cited) have addressed this multiple-versions 
mess; allowing multiple versions coexistence. With OpenVMS and some 
other platforms, not so much.

>> DECset MMS just isn't worth using for app builds.
> 
> Which one is the version-control tool? I never used it, but doesn’t it 
> date from the era when checkout locking was considered mandatory?

DECset MMS is the build tool.  DECset CMS is the source code control.

> I started dipping my toes into VCS with Subversion, and then switched 
> to Git. Yeah, it’s quirky, but it’s very versatile.

DECset CMS is dated, and is not a DVCS.

Mercurial avoids some of the problems that git has, when you're looking 
to use git on not-Linux.

There's a mostly-git-compatible jgit tool that's been available for 
OpenVMS, though that's not been integrated with DECset when last I 
checked.

>> VSI will hopefully be releasing a viable CMake as part of the LLVM> work.
> 
> Interestingly, CMake is best considered as more of a “meta-build” tool. 
> It generates control files to drive platform-specific build tools; e.g. 
> Makefiles on GNU-based systems, Visual Studio project files on Windows, 
> XCode project files on Mac etc.

Xcode can work either with its own project files, or with various makefiles.

As for VS and VSC here, I'm less familiar with those. My early 
experiences with VS were less than positive. Hopefully that's improved.

Eclipse and NetBeans also had issues, and both tended to be slow on the 
platforms I was working with at the time. Ibid.

I've had some success using Xcode with OpenVMS, though that requires 
scaffolding as the numbers of platform-specific calls increase. For 
general source code development, Xcode is just easier than LSEDIT or 
vim or EDT.

> There seems to be an ongoing proliferation of build systems, e.g. I see 
> new names like “Meson” and “Ninja” pop up these days. Not sure if 
> that’s good or bad ...

Build systems have been expanding without bound for some years, yes.  
Some—such as autotools—only seemingly grudgingly work on other 
platforms. (To get autotools working on OpenVMS, y'all need various GNV 
bits from decuserve. Though AFAICT decuserve has been offline for some 
time.) None of the build tools are entirely portable.

How VSP fits together here, we shall learn.

>> And support for isolating apps from other apps is unavailable, whether 
>> for simple collisions of UICs (what a mess UICs have become) ...
> 
> No system for dynamically allocating UICs? On major Linux distros, at 
> least, UIDs for users are dynamically allocated from 1000 up, while 
> ones below that are reserved for “system” use, and are dynamically 
> allocated as part of package installation. So, for example, the “sshd” 
> user might get UID 105 on one system, 107 on another, but it doesn’t 
> really matter.

That's marginally better than what exists for OpenVMS, but is still a 
design straight out of the last millennium. RHEL and some others can 
use a plug-in for allocating identifiers (RH IdM DNA, and prolly an 
analog is available for LDAP but haven't looked), but OpenVMS lacks an 
analogous allocator for both UICs and for usernames. And OpenVMS LDAP 
integration is marginal at best. Using GUIDs—as some platforms 
do—avoids that whole UIC/UID/GID mess. (Who really cares about the 
actual numeric values? Same for app-specific usernames. Who cares? 
OpenVMS does not do well in the whole area of app isolation, not that 
most Linux distros I've worked with here are appreciably better.) App 
bundles and app containers are how various platforms are seeking to 
address the limits here.




-- 
Pure Personal Opinion | HoffmanLabs LLC