On Mon, 31 Jan 2005, Craig A. Berry wrote: > At 7:07 AM -0500 1/31/05, John E. Malmberg wrote: > >> I am looking at building a version that supports the upcoming symlink >> support in OpenVMS, and wanted to know which base level of Perl I >> should start with. > > New development should be done against the 5.9.x development stream > known as bleadperl. The best way to get a copy is via rsync: > > $ rsync -avz --delete ftp.linux.activestate.com::perl-current perl > > This can be done on Linux, Mac OS X, under Cygwin on Windows, among > other unixy environments, and the resulting directory tree zipped up > and moved to VMS. Unless of course you've got your VMS port of rsync > working (which I would be eager to know about).
It is not quite there yet, but I have made significant progress over the past year. I have to convert a number of thread specific static and local variables to be in a thread specific structure, and I think I am past the 50% mark. Unfortunately until I get that step to 100%, I will not be able to do more than verify a converted module compiles. > Some future version. We are still hampered by the fact that certain > parts of the Perl core written in Perl need to be modified to > accommodate the things the CRTL can do. If we don't develop and put > in these changes simultaneously with your changes, basic > functionality will break. For example, if someone has > DECC$EFS_CASE_PRESERVE enabled and the C parts of Perl honor it but > we have not yet modified MakeMaker to handle it, Perl won't even be > able to build itself. I Would expect that it should be a reasonable restriction in at least the short term if not longer, that the CONFIGURE.COM and build scripts for Perl protect them selves from DECC$ feature logicals that prevent them from building. After all, the DECC$ feature logicals will affect the build now even with out the patches. The patches are only needed to make the behavior of the filenames that are not returned from the CRTL consistent with the feature logicals. > So I apologize for how long this has taken. I've been short on > volunteer time that comes in chunks bigger than half an hour, but I > have not forgotten your changes. I was just thinking over the > weekend that we need to move forward with this somehow, and we need > also to look into supporting or using other v8.2 CRTL enhancements, > such as stream-based pipes. Thanks for exploring symlink support. My assigned task now is to get a build of perl that when run under GNV will act like it is running on UNIX, with symlink support. It seems that a number of open source projects now require this. I think that most of the symlink related routines are already in the CRTL now in 7.3-2 and possilbly earlier, except that they will return an error if a symlink is attempted to be created with them, and they will always return the status of no symlinks being present. So programs that do not need to create symlinks or can tolerate that failing should be able to be built now and still work properly when run on a OpenVMS system that supports symlinks. One question that I have is if the Perl self tests will add symlink tests to what it runs if I enable the build of symlink support. I suppose that I will find out soon. Thanks, -John [EMAIL PROTECTED] [EMAIL PROTECTED] Personal Opinion Only
