Mark Berryman wrote:
The GNU way of doing things is specific to GNU and, as far as I can
see, GNU has never been concerned with maintaining backwards compatibility.
Most of the configure scripts I have encountered simply attempt to
compile a short c/c++ program that contains a statement or two but no
include files. If the statement fails, then support must not be
present. To me, this approach explains a lot of the really bad coding
I've seen in some open source projects.
I worked around this by having GNV specify a /first_include switch that
specified a file I had created that set up the necessary environment
(.e.g, define _USE_STD_STAT, _SOCKADDR_LEN, __NEW_STARLET, etc. then
include all of the headers that should have been included by the
configure script's generated programs). This solved the problem for me
except for those configure scripts that include ASM statements. I
should note in passing that I probably haven't used that many configure
scripts.
When I first started using GNV, I tried the /FIRST_INCLUDE hack, and
found out that it did not always work because the CC wrapper also will
sometimes use it depending on the length of the generated DCL command.
In the current GNV, or with the patches available at
ftp.encompasserve.org, the CC wrapper now by default looks for one of
two files to add to the /FIRST_INCLUDE list, either gnv$<module>_first
or if that is not found, gnv$first_include.h in the same directory it
looks for option files. The gnv$ prefix is because configure scripts
were using wildcard deletes of the first include and option files.
GNV for 8.2 and later turns on the _USE_STD_STAT, and can turn on the
/MAIN=POSIX_EXIT based on an environment variable.
There is still more work to be done of course.
-John
[EMAIL PROTECTED]
Personal Opinion Only
