[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #41758] VMS Make incorrectly reports archives support present.

From: John E. Malmberg
Subject: Re: [bug #41758] VMS Make incorrectly reports archives support present.
Date: Sun, 27 Apr 2014 16:50:10 -0500
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

On 4/27/2014 10:04 AM, h.becker wrote:
On 04/26/2014 12:42 AM, John Malmberg wrote:
I have attached a preliminary patch to the default.c module that fixes the
library rules as follows:

1. Create the library if it does not exist when inserting a module into the

Wouldn't it make sense to suppress the check and creation of the
libraries? That is, replace
   "if f$$search(\"address@hidden") .eqs. ..."
   "@if f$$search(\"address@hidden") .eqs. ..."

A quick look shows only a few cases were a default rule output is suppressed. In this case, the output is messy enough that suppressing it is probably warranted.

2. Support all the types of library that VMS does.  Tests still need to be
written for that.

Adding other VMS library types is OK with me. There is one more:
shareable image libarary.

Easily added.

3. Fixes the rcs rules so they have a chance of working.  Of course since
no-one noticed that they did not work due to a syntax error, it might be time
to just remove them.

I agree to remove them.

4. Add a bunch of missing rules.  VMS should have almost all the same rules as
Unix plus some more for VMS specific file extensions and commands.

I don't think that VMS should include all the Posix/Unix extensions. The
Posix subsystem for VMS (had it's own Posix compliant make and) is gone
and GNV is not VMS. I know, I said this before, I think for Gnu make,
GNV should be separated from VMS.

GNU make is needed so that programs ported from Posix sources and posix like makefiles to VMS can be more easily ported.

VMS will use the same file extensions as Posix instead of the defaults, so there is no reason not to support those rules. And this reduces the amount of VMS specific edits needed for a makefile.

It also makes it easier to run the existing self tests to validate the port.

Adding rules to support VMS file types makes sense as an extension, but they should not be instead of the existing expected posix rules.

The recipe for the rules may vary based on GNV or DCL, but all the same rules should be present.

If you are going to force a port to always use VMS specific file extensions for builtin-rules, the person doing the port is probably better off just writing a new makefile to use the MadGoat Make program.

Another question: how should these new pattern rules for non-object
libraries be used?

For objects one can use
   all: o.olb(o)

This syntax will work.

   all: o.olb(o.obj)

This syntax will not work.  It matches the older archive rule.

For the VMS specific library file types, the file extensions can not be in the parenthesis.

Based on the way that Make is interpreting the rules, the extension of the file that is to be added to the library is what determines what type of library will be created.

   all: h.hlp(h)
doesn't work if there are h.h and h.hlp in the same directory.

Help libraries are .hlb, not .hlp.

    all: h.hlb(h)

   all: o(o)
   all: o(o.obj)
   all: h(h)
   all: h(h.hlp)
expected to work?


If the name in the parenthesis has a type, the existing default archive rule takes over, and it will be processed as an object library. It would take a change in how makes handles archive syntax parsing to allow it.

The name in the parenthesis is the module name, and on VMS, the module name can be different than the filename and does not have a type.

 The second rule worked with the old VMS make. With
the new code, always a new library is created. It may break existing
makefiles, so it needs to be documented.

And a comment: on OpenVMS/I64 CXXLINK is not required and not recommended.

The rule for CXXLINK on IA64 can be mapped to LINK then.

And a side note: in the features_archives.gdiff there is a trailing dot
in the filename which prohibits patching the file without manual
specifying the correct filename.

Habit from using VMS syntax with no extensions. I will try to remember that for next time.

Next step is to find out what is wrong with wildcard and vpath with libraries.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]