Conference azur::mcc

Another (related) problem with man/tool/spec


man/tool/spec/lang=(cc,macro)   src$:mcc_decq_am_mgmt_if.ms


places the mcc_decq_am_mgmt_if.h and *.mar files in src$: 

with, get this, .MACRO src$:mcc_decq_am_mgmt_if in the mcc_decq_am_mgmt_if.mar
                       ^^^^
header file. 

This causes the library/insert (/replace) utility to fail.

This has totally BROKEN our AM build.
 

Phil
who_is_not_enjoying_these_incompatibility_problems

Phil,

I noticed these too. For what it's worth, they were the only things I had
to change to get my MSL compiled. The new version of the Toolkit reference
manual documents the lack of an option output filespec on the /LANGUAGE
qualifier. I lucked out on the change, as all I did before was force the
.H and .MAR files into the same directory as the .MS. So I could just take
it out.

The toolkit manual also shows the addition of an /INCLUDE qualifier which 
allows the specification of a directory (or searchlist) from which .MS files 
are INCLUDEd.

re .2

Richard,

Using the /INCLUDE qualifier is what I did to get around it this, for now.
However the problem mentioned in .1 is more serious since we have private and
public builds happening at the same time and se define src$ to be a search list
of the private area and the public (CMS) area. My workaround for NOW was to
auto-edit the MCC*_if.mar files to remove the 'SRC$:' string after the MSL 
Translator executes and before the AM build starts.

I hope that these get fixed to the way they use to work.

Phil 

A language include file specification is not currently supported in
EFT MSL V1.2.

We will look into this to see if this is required so we are backwards
compatible.

    
    Phil,
    
    Sorry to hear we broke your build.  Please bear with us as we absorb
    essential changes necessary for portability.
    
    As you well know file specifications on VMS and Ultrix are not
    portable.  Although we were able to come up with creative solutions for
    most toolkit issues to make the toolkit work on both O/Ss, file
    specifications are one of the areas that we had no control over.
    
    For that reason we have begun to move away from designs where VMS file
    specifications popped up.
    
    If (when) you attempt to port your MM to Ultrix, you'll find that
    this construct results in an "Unknown operation" error from the
    mcc_dispcomp (Ultrix dispatch table compiler).
    
            .MACRO src$:mcc_decq_am_mgmt_if in the mcc_decq_am_mgmt_if.mar
    
    You'll probably end up with something like:
    
            .mcall mcc_yourmm_am_mgmt_if
                                                   
    Although you could argue that the other change is VMS command line
    specific, it is kind of extra baggage which you can easily replace. 
    E.g.:
    
    $ man/tool/spec/lang=(cc=obj$:MCC_DECQ_AM_MGMT_IF.h)
    MCC_DECQ_AM_MGMT_IF.MS
    
    might be replace with:
    
    $ man/tool/spec/lang=cc MCC_DECQ_AM_MGMT_IF.MS
    $ copy MCC_DECQ_AM_MGMT_IF.MS OBJ$:MCC_DECQ_AM_MGMT_IF.H
    
    Sorry we missed getting the help updated in time, but that has been
    fixed in the current baselevel.
    
    
              /LANGUAGES=(language,...)
    
               One or more of the language options indicating the target
               source languages for which the translator is to produce
               output for the associated input file.  By default the output
               definition files are written into separate files in the
               same directory as the associated input file.  It uses the
               file name of its input file and the default file type for
               each compiler to name the target source files.
    
               The language options are:
    
                Language option        File type
                ---------------        ---------
                BLISS-32               .R32
                CC                     .H
                MACRO                  .MAR
                PASCAL                 .PAS
    
    
    If you have trouble modifying your build procedure to work with the new
    release let me know and we'll help you out.
    
    Darryl

re: .5

Darryl, 

I didn't quite follow your explanation on why the name of the macro changed.
With DECmcc V1.1, the name of the macro that defined the symbols was the
name supplied on the MANAGEMENT SPECIFICATION statement in the MSL. This is
the first couple of lines from the .mar produced by the V1.1 MSL compiler:

        .MACRO  MEDIA_LIBRARY_SERVICES,..EQU=<=>,..COL=<:>
;
;  Symbol definitions from MEDIA_LIBRARY_SERVICES.MS

Now the V1.2 MSL compiler puts the name of the MSL file there, which seems
like a step *away* from portability, not towards it:

        .MACRO SRC$:ATLAS_MEDIA_LIBRARY,..EQU=<=>,..COL=<:>
; MSL Version T1.2.4

surely, that isn't right. As Phil noted, the resulting .MAR file can't even
be inserted into an .MLB anymore.

Thanks for clarifying this a little more, sorry that I didn't get it the
first time.

Re .5


>            .MACRO src$:mcc_decq_am_mgmt_if in the mcc_decq_am_mgmt_if.mar
    
>    You'll probably end up with something like:
    
>           .mcall mcc_yourmm_am_mgmt_if


Darryl,

I think you misunderstood me on this. Richard in reply .6 explains 
exactly what I meant.  I believe

		.MACRO src$:mcc_decq_am_mgmt_if
 
is wrong and should be 

		.MACRO mcc_decq_am_mgmt_if 

no matter what the directory was and what the operating system is. I have hard
time understanding how this relates to portability.

The improvements to the development tools in 1.2 are really great and I 
congratulate everyone on it. But please be compatible as much as posible and 
agree to fix any bugs that were introduced. 

I rank the two problems listed in .0 and .1 as:

incompatibility problem:  /lang=(cc=obj$:<fname>.h,macro=obj$:<fname>.h)
                          (and bug in the documentation)

Bug:                      man/tool/spec/lang=(macro) <fname>.ms 
                          resulting in .MACRO src$:mcc_decq_am_mgmt_if
                          instead of .MACRO mcc_decq_am_mgmt_if



Regards,

Phil

The problem discussed in replies .1, .6, and .7 has been entered as
QAR #2211 in MCC_INTERNAL

RE: .8

Answer for QAR #2211 states: "This will be fixed for V1.2"

    <<< Note 2136.9 by COOKIE::KITTELL "Richard - Architected Info Mgmt" >>>

>RE: .8

>Answer for QAR #2211 states: "This will be fixed for V1.2"

	Great. Thanks to all !