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

[John E. Malmberg]

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
> > library.
>
> Wouldn't it make sense to suppress the check and creation of the
> libraries? That is, replace
>    "if f$$search(\"address@hidden") .eqs. ..."
> with
>    "@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.

> and
>    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)

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

No.

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.

Regards,
-John