MMS and the space before the :
Warner Losh
I have a question about MMS. I have perfectly good Makefiles from
Unix. They work on about 20 different flavors of Unix as far ranging
as FreeBSD, SunOS, IRIX, SCO, Unixware and HP/UX, to name a few. I
tried to use it for the VMS port of some software I'm working on, and
found that MMS hates the following valid (imho) Makefile construct:
foo:
It wants it to be represented as
foo :
I am loath to change the Makefile to the latter, but have done so for
the moment.
My question is why? MMS seems to be trying to be compatible with
Makefiles from Unix, yet it fails to accept this basic construct. Is
this a bug in MMS? If so, is there some way that I can report it to
Digitial?
If Digitial is interested in people Porting Unix software to VMS, then
I would rank this problem much higher than the exit() problem that was
posted here earlier :-)
Warner
--
Warner Losh "VMS Forever" home: i...@village.org
Cyberspace Development, Inc work: i...@marketplace.com
Makers of TIA, The Internet Adapter. http://marketplace.com/
Tim Llewellyn
In article <453l22$2...@rover.village.org>, i...@village.org (Warner Losh)
writes:
|>
|>
|>I have a question about MMS. I have perfectly good Makefiles from
|>Unix. They work on about 20 different flavors of Unix as far ranging
|>as FreeBSD, SunOS, IRIX, SCO, Unixware and HP/UX, to name a few. I
|>tried to use it for the VMS port of some software I'm working on, and
|>found that MMS hates the following valid (imho) Makefile construct:
|>
|>foo:
|>
|>It wants it to be represented as
|>
|>foo :
|>
|>I am loath to change the Makefile to the latter, but have done so for
|>the moment.
|>
|>My question is why? MMS seems to be trying to be compatible with
|>Makefiles from Unix, yet it fails to accept this basic construct. Is
|>this a bug in MMS? If so, is there some way that I can report it to
|>Digitial?
|>
I always thought this was because in VMS string: is a valid filespec,
the extra space is required to correctly parse the rule.
|>If Digitial is interested in people Porting Unix software to VMS, then
|>I would rank this problem much higher than the exit() problem that was
|>posted here earlier :-)
Nah, the exit thing requires recoding, this is just a global edit on a
makefile.
|>
|>Warner
|>
|>--
|>Warner Losh "VMS Forever" home: i...@village.org
|>Cyberspace Development, Inc work: i...@marketplace.com
|>Makers of TIA, The Internet Adapter. http://marketplace.com/
|>
--
Tim Llewellyn, Physicist Programmer, Bristol Uni Particle Physics.
HEPNET/SPAN 19716::TJL Internet t...@siva.bris.ac.uk
Soukous, OpenVMS and cricket addict. Doesn't eat animals.
Read at your own risk, standard disclaimer applies.
http://juno.phy.bris.ac.uk/~tjl/
Chris Westbury
i...@village.org (Warner Losh) wrote:
[...]
> MMS hates the following valid (imho) Makefile construct:
>
> foo:
>
> It wants it to be represented as
>
> foo :
>
> I am loath to change the Makefile to the latter, but have done so for the
> moment.
>
> My question is why? MMS seems to be trying to be compatible with Makefiles
> from Unix, yet it fails to accept this basic construct. Is this a bug in MMS?
Alas, DEC does not consider this a bug. From the MMS manual, AA-P119D-TE,
p. 2-2:
=
= If you use a colon to separate the target from the source, insert at least one
= space or tab on either side of the colon, so that MMS does not interpret the
= colon as part of a VMS file specification.
> If Digital is interested in people porting Unix software to VMS, then I would
> rank this problem much higher than the exit() problem that was posted here
> earlier :-)
Second this, and also wish that MMS could do the equivalent of make -r without
my having to write a .COM file.
--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138
Warner Losh
Tim Llewellyn <Tim.Ll...@bristol.ac.uk> wrote:
>I always thought this was because in VMS string: is a valid filespec,
>the extra space is required to correctly parse the rule.
That makes sense. However
foo:
could mean two things. either it means the target foo, or it means
whatever the logical/device foo is. If the latter doesn't exist, then
its meaning is unambiguous. If the latter does exist, then an
ambiguous error should be given, imho.
>|>If Digitial is interested in people Porting Unix software to VMS, then
>|>I would rank this problem much higher than the exit() problem that was
>|>posted here earlier :-)
>
>Nah, the exit thing requires recoding, this is just a global edit on a
>makefile.
Global edit on the makefileS. There are typically more than one
involved in a project of any size.
However, since there already is hacking going on in the makefile, this
isn't too bad. It is just annoying since it is a source code change
(Makefile is part of the source, recall).
Richard B. Gilbert [VAX]
>Makefile syntax is an abomination. Make is an abomination. There are much,
>much better solutions to the problems that make "solves". Unfortunately, make
>is a "standard", so we all have to live with it. But let's not make it any
>worse.
Have any of these "much better" solutions been implemented for VMS?
Are any of these implementations in the public domain? Available
commercially for "reasonable" prices?
As far as I know, make is "the only game in town".
It seems to me that a cheap/free product that was truly superior and
was implemented for VMS, Unix (popular flavors) and Windows/NT would take the
world by storm.
--
*************************************************************************
* Here, there be dragons! *
* DRA...@CIS.CompuServe.Com *
* *
* Richard B. Gilbert *
*************************************************************************
j.lance wilkinson, (814) 865-1818
> Jerry Leichter <leic...@lrw.com> writes:
>
>>Makefile syntax is an abomination. Make is an abomination. There are much,
>>much better solutions to the problems that make "solves". Unfortunately, make
>>is a "standard", so we all have to live with it. But let's not make it any
>>worse.
>
> Have any of these "much better" solutions been implemented for VMS?
>Are any of these implementations in the public domain? Available
>commercially for "reasonable" prices?
>
> As far as I know, make is "the only game in town".
>
> It seems to me that a cheap/free product that was truly superior and
>was implemented for VMS, Unix (popular flavors) and Windows/NT would take the
>world by storm.
Although I agree with Jerry's comments, I don't think that GNU MAKE
or Madgoat's MMK are very high priced, and I'm sure they would solve
the original poster's problem quite well, wouldn't they?
+-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance") InterNet: j...@psulias.psu.edu |
| Systems Design Specialist - Lead BitNet: J...@PSULIAS.BITNET |
| Library Computing Services AT&T:(814) 865-1818 FAX:(814)863-3560 |
| E8 Pattee Library "I'd rather be dancing..." |
| Penn State University A host is a host from coast to coast, |
| University Park, PA 16802 And no one will talk to a host that's close |
| <postm...@psulias.psu.edu> Unless the host that isn't close |
| VMS GopherMeister Is busy, hung or dead. |
+------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
http://perdita.lcs.psu.edu
John E. Davis
: Makefile syntax is an abomination. Make is an abomination. There are much,
: much better solutions to the problems that make "solves". Unfortunately, make
: is a "standard", so we all have to live with it. But let's not make it any
: worse.
I would appreciate it if you elaborate on this point. My main complaint
about make is that there seem to be too many incompatable extensions
floating around. For example, many people write makefiles that require GNU
make.
--John
Jerry Leichter
>Makefile syntax is an abomination. Make is an abomination. There
>are much, much better solutions to the problems that make "solves".
>Unfortunately, make is a "standard", so we all have to live with it.
>But let's not make it any worse.
Have any of these "much better" solutions been implemented for VMS?
Are any of these implementations in the public domain? Available
commercially for "reasonable" prices?
As far as I know, make is "the only game in town".
Most other solutions have been implemented as part of language and compiler
systems. Look, for example, at Modula-3's build language (I forget the name
of the thing). It actually descends from a line of similar programs going
back to work done at Xerox PARC in the late '70's.
Almost all systems built "from the ground up" in the last 20 years have
included a dependency/configuration management tool. PC C environments come
with similar tools - you don't use make with Visual C++, for example!
For supporting traditional languages outside the PC world, people have
generally just given in to the pressure of compatibility with make. Consider
MMS, for example: It's by far the most non-DEC "style", non-VMS "style" VMS
product DEC ever shipped. You could certainly define a more VMS-friendly
syntax, even if you decided you wanted to keep make's semantics.
make's semantics are also becoming more problematical as time goes on. C++
templates, for example, fit very poorly with make. The real problem is that
make depends on "files" as the units of dependency. This is a natural thing
to do in C, which identifies "files" with units of compilation and uses them
as modules (consider file scope) and to define interfaces (.h files). For
languages that support modules and interfaces in some more general fashion,
make isn't a very good tool. (Templates in C++ are a problem because the
same source file produces many "modules", one for each instantiation of an
included template.)
It seems to me that a cheap/free product that was truly superior and
was implemented for VMS, Unix (popular flavors) and Windows/NT would
take the world by storm.
You'll never get it accepted on Unix. For VMS, it's too late to matter. On
NT, make is probably a non-issue - those who come over from Unix may continue
to use it, but those who use PC-derived tools will never touch it.
-- Jerry
Richard Levitte
Second this, and also wish that MMS could do the equivalent of make -r
without my having to write a .COM file.
But it does:
$HELP MMS /RULES
MMS
/RULES
/RULES[=filespec]
/NORULES
...
The /NORULES qualifier directs MMS not to use its built-in rules or
the suffixes precedence list. It also prevents MMS from applying
user-defined rules and default macros. This qualifier is useful when
the description file makes explicit all actions MMS should take in
building a system. When you specify /NORULES, MMS applies only the
dependency rules contained in the description file.
--
+--------------------------------------------------------------------+
! Richard Levitte, GNU on VMS hacker ! tel: +46-8-83 12 15 !
! Södra Långgatan 39, II ! fax: none for the moment !
! S-171 49 Solna ! Internet: lev...@e.kth.se !
! SWEDEN ! !
+-<a href="http://www.e.kth.se/~levitte/gnu/gnu.html">GNUish VMS</a>-+