Conference clt::mms

    Any chance of ever fixing this or add a MM$CHANGED_something that
    returns only the first thing in the MMS$CHANGED_LIST.  348 shows that
    the problem has been known about for over 9 years.
    
                                    August

    Hi August, 
    
    This would be hard to address. Of course, the macro itself can be up to
    ~64K long, but because the only really useful place for it is in action
    lines, the maximum DCL command line length limits the usefulness of the
    macro rather severely. I can't think of any way to get around this
    limitation. 
    
    We can't really change the present implementation without breaking
    existing description files that may depend on the present behavior.
    
    Would your suggestion of an MMS$CHANGED_something really be of use to
    you? What is it that you would really like to see?
    
    This may or may not be helpful, but I can think of a way to cause MMS
    to build a file containing a list of all changed sources; it would
    require a lot of work. Essentially what one would have to do is to
    modify all of the existing built-in rules (as well as any user-defined
    and default rules) to include actions to create the file if it doesn't
    exist (or always create it in a .FIRST), then append the name of the
    current source to the file. It would only require the addition of a
    couple of lines or so, but as I said, every rule would need to be
    modified. The example file MMS$DEFAULT_RULES.MMS would be the place to
    start. However, the resulting rules file would of course have to be
    checked for updates with every new version of MMS.
    
    -- Daryl

>    Would your suggestion of an MMS$CHANGED_something really be of use to
>    you? What is it that you would really like to see?
    
It would be useful to me because it would allow me to implement a mechanism
that reports why MMS is rebuilding a target.  The first thing a rule would
do would be to
    
    write sys$output "MMS$TARGET rebuilt because of MMS$CHANGED_something"
    
Currently I use the following but it blows up with $@ is really long.
    
    .C.OBJ :
        $(QUIET)WRITE SYS$OUTPUT "Compiling $(MMS$SOURCE)"
    .IFDEF WHYC
        - WRITE SYS$OUTPUT "  $? newer than $@"
    .ENDIF
        $(QUIET)IF F$PARSE("CTOPMMS") .EQS. "" THEN CREATE/DIR CTOPMMS
        $(QUIET)mms_file = F$PARSE("$(MMS$SOURCE)",,,"NAME") + "_DEPENDENCIES"
        $(QUIET)@CCOM:CCDECC $(MMS$SOURCE) -
            $(P_MMS_LIST) $(P_MMS_ANA) $(P_MMS_DIAG) -
	    /MMS_DEPENDENCIES=(FILE=CTOPMMS:'mms_file', NOSYSTEM_INCLUDE_FILES)
        $(QUIET)@ccom:MMS_FILTER.COM ctopmms:'mms_file'.mms
        $(QUIET)purge ctopmms:'mms_file'.mms

I have something similar in our UNIX gmake files and it has been invaluable
for debugging make files.  

I suggested a new builtin variable (MMS$FIRST_CHANGED?) as I hoped that it
would be simple to implement.  For my purpose once I know one changed
module's name, I don't particilarly care about the others.

                                    August

    Hi August,
    
    I've raised this as MMS wish #56.
    
    FYI, we are taking a look at other versions of Make tools to see what
    they offer that MMS doesn't, with an eye toward considering adding
    features to MMS. In this case, if the ability to perform manipulation
    on strings such as macros was added, this would address your request,
    because you could then extract any portion of MMS$CHANGED_LIST and use
    it as desired.
    
    If there are any features that you would like to see from any versions
    of Make you know of, this would be the perfect time to request them. In
    fact, I'll create a new topic for that purpose.
    
    -- Daryl

Look at gmake.  We use it on UNIX because of its host of features,
especially the wildcarding.
    
The following generates a list of files in a list of directories and
includes them all.  This is how we include the dependency information files
our C compiler generates.
    
    dependency_includes := $(wildcard $(CMPS:%=$(CDEP)/%/*.d))
    ifneq ($(dependency_includes),)     # if there is at least one file to include
    include $(dependency_includes)      # include them all
    endif
    
With MMS we have use DCL to generate a component.mms file which includes
each of the individual dependency files.

                                    August

    Gmake is at the top of my list for just that reason. Porting it
    directly isn't really feasible, as it doesn't have the CMS interface,
    the CDD interface, the DECwindows GUI, the description file generator,
    etc. But adding at least some of its features may be much more
    practical. I would love to be able to do with MMS the kinds of things
    that can be done with gmake.
    
    Thanks,
    
    -- Daryl