At 7:30 PM -0500 2/4/05, John E. Malmberg wrote: >Craig A. Berry wrote: > >>When GNV gets to the point where we can use Configure rather than >>configure.com and stop maintaining a separate behemoth configuration >>script, that's the point where we will need to update support for GNU >>make. > >There are people looking at getting GNV so that it can handle configure >scripts better. Right now though, it is only being supported by HP on 64 bit >platforms. I do not know if the current GNV source kit will build on VAX.
I don't see any reason to ever disable what is currently working in configure.com, and I don't see us stopping new work on configure.com in the near future, but it would be nice eventually to stop maintaining something that duplicates an existing shell script. >I noticed the post on comp.os.vms about bug reports/fixes to GNV posted to >sourceforge being unanswered, and I will try to find out what is happening >there. > >As I remember things, the Source Forge GNV site was set up by OpenVMS users, >and not by what is now HP. That may be contributing to the communications >problem with items posted there. Of the six people listed as developers on that site, three are names recognizable to me as OVMS Engineering types, though GNV may just be something they contribute to without it being part of their formal job description. >Be assured, bug reports are wanted, and fixes are even more wanted. :-) > >In the case of the INFO-ZIP and VMSTAR that are bundled with GNV, these are >basically maintained externally to GNV and HP, and the HP GNV maintainers are >trying to coordinate changes to them with those maintainers. In the case of Info-Zip, the problem was code that was GNV-specific that went sort of halfway toward allowing case preservation in filespecs. It preserved case but did not do case blind comparisons. The result was that it was impossible to zip up a directory given certain combinations of filename case because foo.DIR did not match foo.dir. I don't think GNV includes VMSTAR anymore, but instead did a new port of GNU tar in order to gain additional features. I can imagine various advantages and disadvantages, but have not done any actual comparisons. >Interestingly enough, SAMBA V4 seems to have changed to using Perl to generate >their configuration information. Other open source projects are also using >Perl as part of their build process. > >And one of the bottlenecks on some of these processes is that they need perl >to only use UNIX format file specifications. Perl has been able to use unix syntax file specification for 10 years or so. If what you mean is the behavior that results from DECC$FILENAME_UNIX_REPORT, that's a different matter. This is a really a problem with other packages not handling file specs reported in VMS syntax. Perl's tendency is that, when in doubt, convert to native syntax. This was essential for older CRTL versions that often did not handle unix syntax fully. But reporintg filenames in VMS syntax will of course cause trouble for other packages that can't handle that. So yes, there is work to be done in Perl to make it only report unix syntax filenames. >Also, to answer your other question, lstat() showed up in 7.3-1 according to >the C header files. On my 7.3-1 system: $ search sys$library:decc$crtl.exe lstat %SEARCH-I-NOMATCHES, no strings matched I suppose it could be a macro that references decc$stat, though I see no evidence of that in the header. >Until 8.2 + future RMS SYMLINKS ECO kit, it behaves the same as stat(), and if >support for lstat() is not configured, Perl already knows to substitute >stat(). And there is no plans to backport these changes to earlier VMS >versions or to implement them on VAX. We'll have to explicitly test for lstat in configure.com, including some sort of test that it not only is present in the CRTL but actually works, i.e., has the underlying OS support. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
