Paul Eggert wrote:
"John E. Malmberg" <[EMAIL PROTECTED]> writes:
The quick patch that I can do is to move where the #undef of the
_GL_JUST_INCLUDE_SYSTEM_DIRECTORY_H is.
Yes, thanks, that sounds like a reasonable fix. I installed the patch
below: does it work for you?
It will take me a little bit to try it.
I still have to manually edit the .h files produced by the makefile.
It looks to me that the configure script is trying to find the path to
the system include directories and then have the makefile put them in
the .h files that it creates.
The configure script can not find the path on VMS because the system
header files are in a text library.
What the VMS compiler does for <zzzzz/file.h> is first search for
zzzzz/file.h in the -I paths, and if it is not found, then searches for
the header file in the compiler specific text libraries.
So what the configure needs the makefile to insert is a non-existant
path like <vms_no_path/file.h>.
Once I find a solution to that, I will be able to get rid of the manual
edits to the .h files and be able to work with editing the .in files.
There are a few other changes for VMS that I have found since my initial
post, but I was waiting for this issue to be responded to. Also, I have
not yet completed the port to VMS. Currently I have the make phase
compiling and linking, but have not tried a make check yet.
Do you want me to submit the patches as I find they are needed, or wait
until I get the final program tested?
From code inspection, I need to replace the routines that call fork()
and pipe() with VMS specific ones similar to what I am using in the port
of Bash to VMS that finally allows VMS to run most configure and make files.
The long term fix to avoid this would be to not use the same names for
the replacement header files as the system header files,
That would mean we'd have to rewrite all our source code that includes
<stdint.h>. We'd rather not do that. If this becomes a real problem
on a lot of platforms I suppose we'll have to rethink things, but for
now the current approach seems to be working OK.
With the header files controlled by X/Open, you can predict what other
headers they will call, but I do not know if there is any standard for
the other system header files. That could change with any patch or
release of the OS. But if you put guards around all of them, it should
work.
It looks like you are trying to do something similar to what I have to
do to work around issues with the C runtime library supplied with VMS.
The VMS C Compiler has the ability to have the user specify a file to be
included before the module being compiled, and I use that to put most
VMS specific fixes/hacks to avoid most modifications to the source.
Since VMS puts guards in the header files to prevent them from being
double included, I can do the include there with macros to modify their
behavior.
-John
[EMAIL PROTECTED]
Personal Opinion Only
