Front page | perl.perl5.porters |
Postings from July 2001
Re: VMS-style command quoting and MakeMaker
Thread Previous
|
Thread Next
From:
Peter Prymmer
Date:
July 9, 2001 16:11
Subject:
Re: VMS-style command quoting and MakeMaker
Message ID:
Pine.OSF.4.10.10107091557280.86512-100000@aspara.forte.com
On Mon, 9 Jul 2001 schwern@pobox.com 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 MM_VMS.pm 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
so:
alist.obj
of_object.obj
files.obj
dll_name.exe/share
and then the corresponding ld command would have to be re-written from
something along the lines of:
$(LD) $(OBJ_FILES)
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 MM_VMS.pm,
> > certainly without littering MM_Unix.pm 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.
OK.
> 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