Conference turris::decc

2126.0. "Suggest enhancement - MMS dependencies" by CSC32::E_VAETH (Suffering from temporary brain cramp, stay tuned) Mon Mar 24 1997 23:28

    This is an enhancement request. If you need an official suggestion SPR,
    I can do that as well.
    
    I had initially posted this in the MMS notes conference.  Since it
    would appear the the compiler generates the dependencies, I am
    submitting this request on behalf of the customer.  If this is not the
    correct forum for this suggestion, please let me know.
    
    thanks,
    
    elin
    
            <<< CLT::DISK$CLT_LIBRARY3:[NOTES$LIBRARY]MMS.NOTE;1 >>>
                         -< MMS general interest file >-
================================================================================
Note 1379.0  How to determine which system headers are included in a   2 replies
CSC32::E_VAETH "Suffering from temporary brain cram" 38 lines  24-MAR-1997 11:28
--------------------------------------------------------------------------------
Hi,

OpenVMS Alpha V6.2 and MMS.

Notes 640 and 1166 are related to this question, however since those notes are
old, I thought I'd start a new one.  Based on those notes, there isn't any easy
way to determine what system header (.H) files are used in the compilation. 

Will this functionality be added to MMS?

Is there an easier way to determine what header file is included?  For example
the CC/MMS qualifier to find out what the include modules are.  His output looks
like this:

   A.OBJ : DKB500:[E_VAETH]A.C  
   A.OBJ : SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB

The customer would like to see:

   A.OBJ : SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB(STRING=STRING.H)

Shouldn't the references to the DECC library include the name of the
module?  

If that isn't the case, then is there an alternative way to determine what
system header (.H) files  are used in the compilation besides what is listed in
notes 660 and 1166?  That information has already been passed to the customer
and the customer feels that suggestion is not very useful.  The complaint is
that the CC/MMS command does not give him the information about which system
headers are used by his program.  If he doesn't know which files to put in the
MMS description file, he cannot do anything appropriate with them.

Thanks,

elin



================================================================================
Note 1379.1  How to determine which system headers are included in a C p  1 of 2
EDSDS6::GLEASON "Daryl Gleason, DECset Engineering"  24 lines  24-MAR-1997 12:55
--------------------------------------------------------------------------------
    Hi Elin,
    
    With respect to the general question of how to determine which header
    files are actually included, CC/LIST/SHOW=INCLUDE will add that
    information the page header of the list file (provided that the include
    file actually spans a full page). However, I don't know of any reliable
    automated way to capture this information for use in an MMS dependency
    unless you want to parse the list file.
    
    I agree that the output of CC/MMS should probably be a dependency based
    upon the module within the library and not the library itself. You may
    wish to take this up with the DEC C group, as the dependencies are
    actually generated by the C compiler and not MMS.
    
    The only way that I can think of for MMS to determine specific
    information on include files would be to enhance the description file
    generator (MMS/GENERATE) to search for this information. However, my
    feeling is that this is beyond the scope of the generator because this
    information is very sensitive to the version of the compiler used, not
    to mention that relatively similar support would need to be added for
    other language compilers. This information is best left in the realm of
    the compilers.
    
    -- Daryl
================================================================================
Note 1379.2  How to determine which system headers are included in a C p  2 of 2
CSC32::E_VAETH "Suffering from temporary brain cramp" 3 lines  24-MAR-1997 23:12
                                  -< thanks >-
--------------------------------------------------------------------------------
    Thank you for the great explanation.
    
    -elin
    

   I've got tools that pull apart the analysis (.ANA) files, and this
   sort of file-level information is in these files  -- what your customer
   appears to be asking for is a way to convert the analysis files into an
   MMS script.

   $ MMS/GENERATE looks like it's the right basic approach, and I'd
   definitely take this request up with the MMS folks...  Point the MMS 
   folks at the analysis file -- the other options are to create some new
   output file from the various languages, or to extend MMS to include a
   set of language parsers to build these dependencies.  (And given the
   analysis files already exist...)

Re: .0

The DEC C project leader and I thought that this was a good suggestion, but
it turns out that it doesn't really work the way the user would want.

Lets say you are maintaining the classic hello.c program, and your
MMS file looks like:

    hello.exe : hello.obj

    hello.obj : hello.c sys$library:DECC$RTLDEF.TLB(stdio=stdio.h)



When you give the MMS command, MMS decides you want to build hello.exe.
MMS checks to see if hello.exe is up-to-date by seeing if its sources
are up-to-date.

The source for hello.exe is hello.obj.  MMS sees if hello.obj is up-to-date
by seeing if its sources are up-to-date.  The sources for hello.obj are
hello.c and the stdio module in the text library.

MSS then tries to see if stdio in the text library is up to date, and so
MMS tries to check if stdio.h is up-to-date.

The user doesn't have any source for stdio.h, and so MMS complains:

%MMS-F-GWKNOPRN, There are no known sources for the current target
  sys$library:DECC$RTLDEF.TLB(stdio=stdio.h).


The problem is that MMS "knows" that object libraries and text libraries
are derived objects.  When you reference a module in a library, MMS checks
to see if that module is up to date by seeing if the file used to create
that module is up to date.  If the file is newer than the module in the
library, MMS inserts the file into the library replacing the out of date
module.

This behavior is great if you are creating your own text libraries from
your own header files.  It's not useful when you want to see if the
"system" headers (stored only in text library form) have been updated.

DEC C/C++'s current behavior of saying the program depends upon the text
library file itself seems to be the best solution.

Sorry, I had thought this was a good suggestion.