Dear Jouk,
Thank you for prompt reply!
On 2024/10/01 17:37, Jouk Jansen wrote:
mpsuz...@hiroshima-u.ac.jp 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
