[Info-vax] C and C++ and clanger-free clanging (was: Re: Porting to Linux instead of x86-64 VMS, ...)

[Stephen Hoffman]

On 2019-07-03 20:25:05 +0000, Hans Vlems said:

> Hoff, what I understood from John’s post is that the clang.exe is 
> present on x86/VMS. It will be available thru DCL for just one purpose: 
> to compile c++What follows is basically, well, since clang.exe is there 
> anyway you can use all of its features, like its ability to compile C.  
> Provided you’re willing to figure out the required options to make that 
> work (500+ options, right?).And I doubt that VSI will entertain 
> questions about any other way of using clang other than the way DCL  
> knows about. Hans

Well aware.

Background: LLVM is the back-end for everything, and there's been a 
running discussion around the front-end support.  The initial support 
is all around compatibility with the existing source code, which is 
reasonable.

I'd prefer that steps be taken early on to make the environment drift 
toward newer and less complex, and away from adding complexity to adopt 
newer standards and practices, but that's fodder for many discussions.

Been working else-platform with clang for a number of years and for C 
and C++ and Objective C development, and with an IDE.  Really liking 
the IDE capabilities, too.  Far past what LSEDIT offers on OpenVMS.  
Been doing some OpenVMS C++ work using that same IDE, too.  Far more 
effective than doing traditional OpenVMS development, though the lack 
of OpenVMS integration is problematic.

As for clang and switches, I usually ask the native IDE to show the 
clang switches used, and fill in a field to select the specific include 
and library paths.  I'm scripting a few of the builds and which means 
wading into the clang switches, and that particularly for portable 
code.  But for local other-platform app development using the IDE, not 
so much.

I don't expect either clang usage nor IDE usage to be mainstream on 
OpenVMS anytime soon, though there are finally starting to be some 
cracks in the long-standing development practices and tooling for 
OpenVMS.  Which is a hopeful sign.  As for what's become available for 
OpenVMS, been starting to play with Visual Studio Code but for a 
different project and purposes—that's also part of Unity, which is 
something I've been looking at—and haven't tried the OpenVMS VSC bits 
quite yet.


-- 
Pure Personal Opinion | HoffmanLabs LLC