Discussion:
VMS can not include "float+.h"
John E. Malmberg
2017-06-15 00:08:56 UTC
Permalink
I seem to have coerced configure into running on NFS served files
created by on VMS using GNV updated kits.

rm -rf ${GNU_MIRRORS}/gnulib/gnulib
./gnulib-tool --create-testdir --with-tests
--dir=${GNU_MIRRORS}/gnulib/gnulib

# Work around some issue with NFS timestamps.
pushd ${GNU_MIRRORS}/gnulib/gnulib
sleep 5
touch Makefile.in
touch configure
touch config.h.in
popd

The make step fails at c-vasnprintf.c because the VMS C compiler can not
handle the "float+.h" filename as below:

.. -DGNULIB_STRICT_CHECKING=1 -g -c -o c-vasnprintf.o c-vasnprintf.c

# include "float+.h"
..^
%CC-F-NOINCLFILEF, Cannot find file "float+.h" specified in #include
directive.
at line number 94 in file GNULIB_ROOT:[gnulib.gllib]vasnprintf.c;1
make[4]: *** [c-vasnprintf.o] Error 2


Normally I work around this by running a script before the make step
that replaces the "float+.h" to something like "float_plus.h" and then
copying the float+.h file to be float_plus.h.

Regards,
-John
Paul Eggert
2017-06-15 04:46:47 UTC
Permalink
Post by John E. Malmberg
The make step fails at c-vasnprintf.c because the VMS C compiler can
not handle the "float+.h" filename
Perhaps Gnulib source files should be renamed to use just the characters
in the POSIX Portable Filename Character Set
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282>.
The "+" character is the only one that appears in Gnulib source file
names but not that character set. This would be a nontrivial change,
though, e.g., some module names would have to change (e.g., "no-c++").
Bruno Haible
2017-06-15 09:13:46 UTC
Permalink
Post by Paul Eggert
Perhaps Gnulib source files should be renamed to use just the characters
in the POSIX Portable Filename Character Set
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282>.
I vehemently disagree. The relevant file name restrictions nowadays are
those of Windows (no characters " * / : < > ? \ , file names don't end in '.',
file names avoid special names such as "aux", "nul", "prt"). We have been
leaving the 8+3 restrictions of Windows 3.1 (which disappeared from the
marked around 1995-1997) between 2000 and 2011. Before that, it was
commonplace that packages targeting DOS platforms had a special script
for renaming the source files (e.g. [1]).

VMS is a very small niche system. If such a renaming of source files was
possible for DOS, it must equally be possible for VMS.

Other GNU packages that use the '+' character in file names, independently
of gnulib:
gcc, glibc, binutils, coreutils, bison, gettext, clisp, gperf.

POSIX is partially outdated, as has already been noted on this list. [2]

Bruno

[1] http://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=blob;f=djgpp/fnchange.lst
[2] https://lists.gnu.org/archive/html/bug-gnulib/2017-02/msg00069.html
John E. Malmberg
2017-06-15 14:05:27 UTC
Permalink
It should only be include files VMS has issues with.

Regards,
-John
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bruno Haible
2017-06-15 15:41:13 UTC
Permalink
Post by John E. Malmberg
It should only be include files VMS has issues with.
I said NO. Even if it's only for 1 file, I don't want to go backwards in
time by 20 years.

Deal with it on your side. I've given you a pointer how such issues were
dealt with regarding DOS file names.

Bruno
Paul Eggert
2017-06-15 19:26:29 UTC
Permalink
Post by John E. Malmberg
It should only be include files VMS has issues with.
If that's the problem, then it shouldn't be much trouble to have a
separate script that rewrites the file names and source code to follow
the POSIX portable filename rules. We could include that script as a
separate file in Gnulib, or perhaps as a gnulib-tool option. This would
avoid the need to change existing code, and I assume Bruno would be OK
with something along those lines.

That being said, wouldn't it be simpler for you to switch your VMS
development host's file system to ODS-5? That way, you should be able to
use these file names as-is, and you'll be less likely to run into
similar problems with programs other than Gnulib.
John E. Malmberg
2017-06-15 22:56:24 UTC
Permalink
Post by Paul Eggert
Post by John E. Malmberg
It should only be include files VMS has issues with.
If that's the problem, then it shouldn't be much trouble to have a
separate script that rewrites the file names and source code to follow
the POSIX portable filename rules. We could include that script as a
separate file in Gnulib, or perhaps as a gnulib-tool option. This would
avoid the need to change existing code, and I assume Bruno would be OK
with something along those lines.
I already have a VMS specific edit script that can update the 7 modules
in gnulib that include float++ that I can run as part of a prebuild script.

At the time I made that reply, my only Internet access was a small cell
phone screen, so it was both hard to type or read other pages.

For this pass, I am mainly trying to get everything to compile with a
minimum amount of VMS specific changes and support files.
Post by Paul Eggert
That being said, wouldn't it be simpler for you to switch your VMS
development host's file system to ODS-5? That way, you should be able to
use these file names as-is, and you'll be less likely to run into
similar problems with programs other than Gnulib.
The development host system is ODS-5 on Alpha/IA64.

The not handling of #include "float++" is a bug in the compiler that was
recently discovered when I updated the GNV Coreutils package.

The compiler also sometimes has problems with #include "../xxxx.h",
which need similar edits to work around.

Regards,
-John

Loading...