On Tue, 15 Feb 2005 [EMAIL PROTECTED] wrote: > "John E. Malmberg" <[EMAIL PROTECTED]> wrote on 02/15/2005 > 03:21:01 PM: > > > If anyone has any suggestions on an easy way to do this, please let me > > know. > > I'd recommend rewriting config.h before you compile perl under GNV, later > you could modify the Configure script itself to recognize GNV as a > distinct osname. Here for example is how perl 5.8.1 is built to recognize > VMS:
Yes, I modified the configure.com script to allow osname=GNV. The build has completed and it is running the tests now. I am noticing on a previous build that a number of the tests are failing when you build with the VMS DEBUG option, and the tests use PERLSHR instead of DBGPERLSHR. When the tests are run using DBGPERLSHR they succeed. This is telling me that when the VMS DEBUG option is selected, PERLSHR is not being built correctly. > $ search PERL_ROOT:[LIB.VMS_AXP.5_8_1.CORE]config.h osname > /* OSNAME: > #define OSNAME "VMS" /**/ > Of course changing that and recompiling does not give you the flexibility > of a symbol or logical that you requested. However there is precedent for > such a distinct setting of $^O. Namely the Windows native port calls itself > 'MSWin32' whereas the cygwin (GNU/bash et al) environment calls > itself 'cygwin' in perl's $^O variable. Yes, I noticed that. The cygwin is a more isolated container environment than GNV is, and while I might have to settle for a separate binary, I would prefer that a system could have one installation of Perl for all of it's uses. That the build proceded completed with the -Dosname=GNV and the self tests are generating an active display on the monitor system command is encouraging. -John [EMAIL PROTECTED] Personal Opinion Only
