Re: Recent change of apinames_vms.bash

Dear Jouk,

Thank you for prompt reply!

On 2024/10/01 17:37, Jouk Jansen wrote:
> [email protected] wrote on 30-SEP-2024 12:24:47.86
> 
>> 1) Bash on VMS cannot invoke the DCL commands?
>>
>> File renaming is very basic task of the operating systems
>> with a file system. It seems that VMS has a DCL command
>> to do that, "RENAME". If "RENAME" is usable from Bash script,
>> it would be more portable than using /gnu/bin/mv. Is it
>> impossible?
> 
> We are foved to use bash here, because of a difference in interpreting wild
> cards between bash and DCL. apinames_vms needs it expanded on the command
> line and cannot interpret the wild card. So I need bash.
> 
> Basically you can also put the RENAME command just below the bash command in
> vms_make.com. But it is better to keep this command together with the
> creation of it in one script. You need bash anyway and bash on VMS comes
> with the GNV package that also contains mv.

I see. Your point is: the developer working on VMS must have GNV package,
so no need to care about the availability of "mv" command... Right?

>> 2) Why freetype_vms0.opt is needed?
>>
>> Current apinames_vms.sh generates freetype_vms0.opt,
>> and rename it to freetype_vms.opt immediately, regardless
>> with the status returned by apinames.
>> Writing directly to freetype_vms.opt is bad idea?
> 
> If freetype_vms.opt already exists (i.e. from an earlier build), the file
> gets appended and al entries are doubled resulting in an error further on in
> the build procedure. This is a way around it.

Oh, excuse me, please let me confirm. On conventional Unix systems,
the redirection by ">>" would append the existing file, but
the redirection by ">" would overwrite the existing file.
The bash on VMS works differently? ">>" and ">" have no difference?
  
>> 3) The "-o" option of apinames is not helpful?
>>
>> The default output of "apinames" is the standard output,
>> but apinames has the "-o" option to specify the output filename,
>> since its first appearance on 2005. Is there any special
>> reason to let apinames write to the standard output,
>> and let the shell redirect it to freetype_vms0.opt?
> 
> I did not test that.

I see...
  
>> 4) VMS users do cross building for VMS running on different CPU?
>>
>> This question is quite different from 3 questions in above :-)
>>
>> VMS has migrated among several architectures, from VAX to Alpha,
>> then from Alpha to Itanium, and from Itanium to x86-64. For VMS
>> users, the cross building for VMS on different architectures are
>> popular usecase? If it is popular, the cross compilers are
>> separated for each target architecture, like conventional
>> GNU toolchains (e.g. vax-netbsdelf-gcc alpha-netbsdelf-gcc, etc)?
>> I'm unfamiliar with the convention of LLVM-based SDK.
> 
> Native compilation is the way to go on OpenVMS. The only cross-compilers I
> know of are
>     -gcc on linux to build for Itanium. It is an old version of gcc and very
>      hard to build. Only one or thow people have it running.
>     -Cross copilers running on OpenVMS-IA64 for OpenVMS-x86. They are mainly
>      use by VSI (the manufacturer of OpenVMS) to have a quick-start on
>      x86-64. and available to only selected users. The plan is to phase those
>      cross-compilers out in the future.

Thanks! Very informative, especially the future of VSI cross compiler.
Just I've checked the free-charged licensing program of OpenVMS,
it seems that the community license for x86-64 architecture is possible,
but no community license for Alpha and Itanium. Which architecture do
you use? Just I've submitted my request for x86-64 architecture...

Regards,
mpsuzuki