develooper Front page | perl.perl5.porters | Postings from July 2001

Re: VMS-style command quoting and MakeMaker

Thread Previous | Thread Next
Peter Prymmer
July 9, 2001 16:11
Re: VMS-style command quoting and MakeMaker
Message ID:

On Mon, 9 Jul 2001 wrote:

> On Mon, Jul 09, 2001 at 02:01:07PM -0700, Peter Prymmer wrote:
> > There is considerably more to MM_VMS than just the double quotations.  In
> > fact I would assert that much of is: 
> > 
> > 0) getting around DCL's 255 character command line limit (that affects
> > command lines run from MMS or
> > MMK make utilities)
> Eeek, you can keep that.

It is a considerable pain in many ways.

> > 1) changing 'alist.o of_object.o files.o' to 
> > 'alist$(OBJ), of_object$(OBJ), files$(OBJ)' (note the use of the commas in
> > the latter) 
> Hmmm, should be able to make the MM_Unix methods to be more flexible
> about their extensions, but the commas thing might be tricky.

Possible correction: on unix you'd likely see a list of files in a
Makefile like so:

	alist$(O) of_object$(O) files$(O)

that is, space separated.  On VMS _provided the list fits the 255 rule_
they'd have to be comma separated.  If the list does not fit the 255 rule
(and provided it is something suitable for the linker to work with, like
object files and/or dlls) it could be turned into a line-feed separated
list but would have to be written out to a separate file (it is known as a
"linker options file" file in VMS parlance.  An example might look like


and then the corresponding ld command would have to be re-written from
something along the lines of:


to something that looks like:

	$(LD) module_name.opt/opt

er, more or less.

> > Hence it may prove difficult or impossible to get rid of,
> > certainly without littering with oodles of C<if ($^O eq 'VMS')>
> > which kind of defeats the whole code re-use idea of MakeMaker.
> Oh, it will always be around, yes.


> My Grand Plan is to split out much of the generic bits of MM_Unix into
> MM_Virtual which would act like a real base class with real virtual
> methods.  Hopefully eliminate alot of the C<if $^O eq 'Win32'>
> exceptions already in MM_Unix.
> The big problem is MakeMaker violates the seperation of form and
> functionality so often.  Most methods spit out formated Makefile
> fragments instead of a data structure which can then be formatted.
> Alot of the work of building a useful MM_Virtual will be seperating
> most of the methods into "thing that returns the data" and "thing that
> formats it".
> For example, your list of object files above might instead be overridden as:
> 	sub objects {	# I forget what the real name is
> 	    my($self) = shift;
> 	    my @object_files = $self->object_files;
> 	    return join ', ', map { $_.'$(OBJ)' } @object_files;
> 	}
> so the work for porting MakeMaker is reduced to writing a formatting
> wrapper method.

That sounds reasonable.  I cannot help but think that there may be a Unix
&& Shell && make-utility combination that might _not_ like C<"-I../lib">
in place of C<-I../lib> command line quoting hence I think that 'talking
to the system CLI' ought to be as well abstracted as will allow.

Another problem that has arisen in porting to weird platforms is the
testing for the presence of libraries (though this tends to be Makefile.PL
specific rather than MakeMaker specific).  On OS/390 there is a separate
file system that is not accessible to perl's -x file stat operators, hence
gives MakeMaker the mistaken impression that a needed dll is missing.
There are a limited number of shell utils that can handle the problem (cat
can but ls cannot e.g.) and the C RTL has extensions to fopen() that allow
a C or XS based approach to simulate a stat() that can be made to work the
"alternate filesystem".  This is a tough problem, and may be one that
MakeMaker cannot be expected to work around, but I thought you might want
to keep it in mind.

Peter Prymmer

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About