Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig A. Berry wrote: At 11:40 PM -0500 3/3/05, John E. Malmberg wrote: Building an on-the-fly program, usually called try.c, is the standard way to go. There are quite a few examples in configure.com. There is no reason to even run the test on VAX or on non-VAX prior to v7.3-1. I will see about writing such a program for hard links being enabled, right now, I can only easily test it on 8.2. What do you need for a patch to be submitted? GNU unified diffs of any files that have changed would be ideal. It's not clear to me to what extent the various changes you have in progress can be separated out, but I'm willing to help with the separating if you have something we can go ahead and get into bleadperl. I'm assuming configure.com, [.vms]vmsish.h, and [.vms]descrip_mms.template at a minimum are involved. Actually as I posted before, there are two modules utils/c2ph.pl, x2p/pl, involved that you provided a better change to, and a change to configure.com to enable hard links. No changes to vmsish.h or descrip_mms.template are needed. It may be better to change the .PM modules so that for the VMS platform they can detect if hard links are available on the target, or detect that the link() call fails, they then fall back to the copy, and have the hard link test also skip that tests when hard links are not available. That way perl can be built with hard link support even on disks that do not support hard links. The only real outstanding issue for me with hard links is that the perl umask function is not working as expected, and this is only effectively tested if hard links are enabled. It looks like that perl test [.t.io]fs.t is wrong. It should be testing to see if the first file protection mask matches the what was set by the umask() call, even when hard links are not enabled. Then it should be checking to see that the triply linked file has the same umask as the original if hard links exist I probably will not have time to find out why the perl umask code is not working as expected for a little while as that appears to be an existing bug. It also appears that umask issues are present on other platforms as there are special case codes in the test. I will see what I can do to get some patches for bleadperl. Actually there really should not be any reason not to enable large file support when it is available. I think it's slower, and also we try to track whatever defaults the unix builds use. I do not see why it would be slower, it is probably just alternate inputs to the same I/O routines with larger data types for the transfers. Are the UNIX builds not auto-enabling large file support when they detect that it is available? -John [EMAIL PROTECTED] Personal Opinion Only
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
At 11:40 PM -0500 3/3/05, John E. Malmberg wrote: At this time, I can only test it on v8.2, and v8.2 is the earliest that DCL can easily check to see if hard links are available. The lexical function to check if hard links are enabled on the hard drive starts with v8.2. For prior versions, either the output of $SHOW DEVICE/FULL would need to be parsed, or a temporary program written to do the test. Building an on-the-fly program, usually called try.c, is the standard way to go. There are quite a few examples in configure.com. There is no reason to even run the test on VAX or on non-VAX prior to v7.3-1. What do you need for a patch to be submitted? GNU unified diffs of any files that have changed would be ideal. It's not clear to me to what extent the various changes you have in progress can be separated out, but I'm willing to help with the separating if you have something we can go ahead and get into bleadperl. I'm assuming configure.com, [.vms]vmsish.h, and [.vms]descrip_mms.template at a minimum are involved. I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. It may be counterintuitive that one has to enable large file support in order to also get symlink support. But I don't have a better suggestion at the moment. Actually there really should not be any reason not to enable large file support when it is available. I think it's slower, and also we try to track whatever defaults the unix builds use. There is a lot of work to get the symlink stuff working, because it also requires getting Perl to honor the DECC$FILENAME_UNIX_ONLY and DECC$FILENAME_UNIX_REPORT logical names every where it returns a filename. Yup. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
On Mon, 28 Feb 2005, Craig Berry wrote: I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If you specify more than one macro definition in ccflags the /DEFINE macros need to be in parenthesis. This causes the test lib/ExtUtils/t/Embed.t to fail because it passes the parenthesis back with an \ character in front of them to the DCL command. It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. -John [EMAIL PROTECTED]
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
At 8:26 AM -0600 3/3/05, John E. Malmberg wrote: On Mon, 28 Feb 2005, Craig Berry wrote: I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If you specify more than one macro definition in ccflags the /DEFINE macros need to be in parenthesis. This causes the test lib/ExtUtils/t/Embed.t to fail because it passes the parenthesis back with an \ character in front of them to the DCL command. Hmm. We may need to modify the test to do for /DEFINE what it already does for /INCLUDE. It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. Excellent. I look forward to your patch. I suppose there's no reason to do the check unless we're on v7.3-1 or later. I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. It may be counterintuitive that one has to enable large file support in order to also get symlink support. But I don't have a better suggestion at the moment. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig A. Berry wrote: At 8:26 AM -0600 3/3/05, John E. Malmberg wrote: It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. Excellent. I look forward to your patch. I suppose there's no reason to do the check unless we're on v7.3-1 or later. At this time, I can only test it on v8.2, and v8.2 is the earliest that DCL can easily check to see if hard links are available. The lexical function to check if hard links are enabled on the hard drive starts with v8.2. For prior versions, either the output of $SHOW DEVICE/FULL would need to be parsed, or a temporary program written to do the test. What do you need for a patch to be submitted? I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. It may be counterintuitive that one has to enable large file support in order to also get symlink support. But I don't have a better suggestion at the moment. Actually there really should not be any reason not to enable large file support when it is available. There is a lot of work to get the symlink stuff working, because it also requires getting Perl to honor the DECC$FILENAME_UNIX_ONLY and DECC$FILENAME_UNIX_REPORT logical names every where it returns a filename. -John [EMAIL PROTECTED] Personal Opinion Only
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
On Monday, February 28, 2005, at 02:58PM, John E. Malmberg [EMAIL PROTECTED] wrote: The perl hack to produce a consistent dev_t st_dev will proably not work on symbolic links and mount points. So to support them I will have to make sure that the modules are built with the correct structure sizes. As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE did, it needs to be defined in the MMS files. Also, support for getpgid() will require that the feature macro __USE_LONG_GID_T be defined. It therefore looks like a change is needed to allow the configure script to pass a list of macros to be appended to a /define=() switch on the C compiler. If a harmless macro is specified in the MMS file for the cases where there are no extra macros to be defined, this would simplify the coding required to make this change That way the Configure script can do something that results in: BUILD_MACROS=,_LARGEFILE=1,_USE_STD_STAT=1,__USE_LONG_GID_T I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). And where it is used: /MACRO=(VMS_NULL_ARG($)BUILD_MACROS) /MACRO=(X2SUBP($)BULD_MACROS) As I noted in my IEEE posting, I know how to make it work for the descrip_mms.tempate, but not the other generated descrip.mms files. If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly.
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig Berry wrote: On Monday, February 28, 2005, at 02:58PM, John E. Malmberg wrote: The perl hack to produce a consistent dev_t st_dev will proably not work on symbolic links and mount points. So to support them I will have to make sure that the modules are built with the correct structure sizes. As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE did, it needs to be defined in the MMS files. Also, support for getpgid() will require that the feature macro __USE_LONG_GID_T be defined. It therefore looks like a change is needed to allow the configure script to pass a list of macros to be appended to a /define=() switch on the C compiler. If a harmless macro is specified in the MMS file for the cases where there are no extra macros to be defined, this would simplify the coding required to make this change That way the Configure script can do something that results in: BUILD_MACROS=,_LARGEFILE=1,_USE_STD_STAT=1,__USE_LONG_GID_T I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). Annother option is to use the /FIRST_INCLUDE option. And where it is used: /MACRO=(VMS_NULL_ARG($)BUILD_MACROS) /MACRO=(X2SUBP($)BULD_MACROS) As I noted in my IEEE posting, I know how to make it work for the descrip_mms.tempate, but not the other generated descrip.mms files. If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If I understand your uselargefiles change, you used a variable substitution for ~LARGEFILES~ and passed it as a parameter to the script that built the outer descrip.mms. I did not see a ccflags change, but I will look for it tomorrow. Did you get a chance to look at the hard link support modifications that I posted about? I am not sure how to resolve the issue on the test that fails. I think it is wrong for a test script to assume that the default protection would be PROT=(O:RWD, G:RWD, W:RWD). -John [EMAIL PROTECTED] Personal Opinion Only
