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

[Simon Clubley]

On 2019-07-03, John Reagan <xyzzy1959 at gmail.com> wrote:
>
> For the CXX DCL interface to clang++, I don't see us providing an
> arbitrary /CLANG_OPTIONS="random string".  We'll provide a reasonable
> mapping for the existing DCL syntax for the "recompile-and-go" crowd. 
> We'll probably add some support for various common hardware flavors with
> /ARCH.  Maybe a few others.  But if you want to specific lots of strange
> exotic options, use the foreign command form.  That said, if you compile
> without -fPIC (and perhaps a few other ones), the object probably won't
> link/execute correctly.  In order to support shareable images,
> INSTALL/RESIDENT, etc., you must compile with -fPIC.  The DCL interface
> will set that for you.  We'll provide guidance when the time comes.

Please do not give in to any pressure to add an option along the lines of
/CLANG_OPTIONS="random string" as that would cause all kinds of problems.
For example, what happens when the manually entered options conflict with
the options added by the other DCL qualifiers ?

I think the approach you are taking is the best of both worlds:

Ie: provide a front end driver which automatically maps the existing DCL
language qualifiers into clang options but require the user to directly
learn the clang options when they want to do something more complex.

They are going to have to learn something new anyway (either a newly
made-up DCL qualifier or the appropriate clang option) so they might
as well learn the clang option that everyone else uses instead of
learning a VMS specific qualifier and then having to carry around
a DCL qualifier to clang mapping table.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world