On Mon, Dec 09, 2002 at 12:51:24PM -0500, [EMAIL PROTECTED] wrote: > !Does anyone know why it's done that way? Our version keeps getting > !out of synch with the MM_Unix version that all other platforms use, > !and it would be much more maintainable if we could get rid of the > !override. I also notice that continuation lines are scrupulously > !avoided in [.vms]descrip_mms.template; is there any good reason for > !that? > > That is certainly a pain. I suspect (although I do not actually > know) that the assignment of the macros was done that way to > avoid an allocation limit of some sort (along the lines of the 255 > limit for DCL lines passed into lib$spawn()). Admittedly macros > are data structures internal to the build tool and their assignment > /concatenation build up statements should not have > to worry about DCL limits (they are not action lines after all). > Perhaps there was an old version of MMS that needed such spoon > feeding? I suspect that Charles Bailey might remember why it > was done that way. Isn't it the case that you always use MMK? > > As to possible solutions: why not have the perldepend portion > of MM_$platform.pm built up from a .PL extractraction by > miniperl at perl build time? I suspect the only tricky bit would > be the maintenance of ExtUtils::MakeMaker outside of the perl > source build process. But at least the headache of header listings > would be lessened.
This is what I hope to do, but first I want to remove the duplication between the MM_Unix->perldepend and MM_VMS->perldepend, the big list of header files, which lead to this make format question. Doing it outside the core isn't any harder, you just use arch/CORE/*.h. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Anti-cow device. Don't bother. http://www.goats.com/archive/990323.html
