MMS/CMS: What targets depend on a given source?

[Brad McCusker]

This question is one of those issues that I just assumed could be done, but, after trying to figure it out, it appears that I assumed wrong.

The issue is with MMS and CMS. Given an MMS descrip file with all the usual targets, source, dependencies, rules, etc, is there an easy way to determine which targets are dependent on a given source? More directly, if I change source.c, which executables are affected?

Let me explain:

Assume this simple descrip file:

***Begin DESCRIP file****

ALL : group1, group2

group1 : a.exe,c.exe,

group2 : b.exe,d.exe

a.exe : src1.obj,src2.obj

b.exe : src3.obj,src4.obj

c.exe : src1.obj,src4.obj

d.exe : src2.obj,src4.obj

****End DESCRIP file*****


What I want to do is determine which targets need to get rebuilt if I change, for example, src1.c.

MMS would build the affected executables if I had all the executables in my working directory or CMS, etc, but that is not an option in this situation.

As far as I can determine, there is no obvious, straight forward way to have MMS tell me that if I change src1.c, the affected targets are a.exe, c.exe, group1, and all.

(What I really want to know is the .exe's affected, so, in the previous example I would eventually filter out the mnemonics group1 and all)

I'll probably solve my problem by parsing the descrip file. That won't be too difficult. But, before I went to that trouble, I thought I'd ask just to be sure I wasn't missing something obvious in MMS or CMS.

[Ian Miller.]

what about using
MMS/NOACTION/LIST
to see what MMS would have done?

[Steven Schweda · Accepted solution]

I don't immediately see anything better than
that. Of course, you might need to loop
through your list of targets and look at the
status to see if it was already happy or not.

I think that you want to let MMS figure this
out, rather than "parsing the descrip file"
yourself, unless you're interested only in
very simple description files.

Note also: MMS /CHANGED = [...]

[Hoff]

There isn't a way that I'm aware of, short of the verification approach suggested.

I've become quite fond of the brute-force application build.

Dependency builds seem quite elegant, but unfortunately seem to be as much of a labor sink as a labor savings.

Errors in the dependency graph can be really nasty. Throwing hardware at the problem can make this all go away -- there's a definite cost to the processor savings from an incremental build, and a fast processor and fast I/O can greatly reduce those benefits.

The brute-force approach toward determining dependencies -- without involving MMS -- is to work backwards from the maps and the listings -- this is how an organization that shall remain nameless has traditionally maintained that sort of information.

Stephen Hoffman
HoffmanLabs

[Brad McCusker]

Thanks for the help...

Ian - the "/NOACTION/LIST" approach won't help because I still need to tell it to build something, i.e give it a target. That's essentially what I'm trying to figure out. Though, it might come in handy with SteveS's suggestion.

StevenS - /CHANGED appears to be exactly what I want. I don't know how I missed that, but, it sure looks like it's giving me what I want.

Hoff - In this case, it's not an issue of minimizing what we build. We have plenty of horsepower. The issue is, I want to *know* which images are affected by a source change so that we can make informed decision on what we build, test and put into production. We want exactly and only those images which are affected. No more and no less. The good news is, the system is relatively static, so, the risk of messing up dependencies and such is relatively low - they haven't changed in a long time.

That "static" nature of things is also part of the problem. We make a change to a module, put it into production in a given image because we "know" that image is affected, but, we don't realize there are other images affected. Then, months later we sometimes get surprised when one of those other images unexpectedly picks up that change.

Thanks gain folks!

Brad McCusker
Software Concepts International

[Hoff]

>>>
That "static" nature of things is also part of the problem. We make a change to a module, put it into production in a given image because we "know" that image is affected, but, we don't realize there are other images affected. Then, months later we sometimes get surprised when one of those other images unexpectedly picks up that change.
<<<

I've certainly encountered that case.

The fix is to run the full build and at least a cursory regression test regularly, as to do otherwise means that cruft inevitably creeps in.

These things have a nasty habit of blowing up in odd and unexpected ways, even after you go to the effort of eye-balling the source code and the change.

That, you'll want to preserve the full maps and full listings (with machine code) for everything you release.

[Willem Grooters]

This might be a (partial) solution:

If you specify the location (using logicals, of course) it would probably help:

Group1: a.exe, c.exe
group2: b.exe, d.exe

a.exe: obj:src1.obj, obj:src2.obj
b.exe: obj:src3.obj, obj:src4.obj

Define/job obj as a searchlist referring the expected locations, it will locate the files.

WG