On 8/12/2017 7:35 AM, Seymour J Metz wrote:
WTF? The whole point of SMP is that *SMP* tracks dependencies.
SMPE can only track dependencies it has been told about. Somehow they
need to be tracked prior to that so they can be added to the SMPE packaging.
It's trivial to take interface changes into account. Of course, that5 takes
proper packaging, but you don't blame the hammer when someone uses it do drive
in a screw. CVS, git, SMP, subversion, etc., are not magic bullets and should
not be judged based on how people who don't understand them might misuse them.
The same bookkeeping needed to avoid a bad build gives you the information that
you need for SMP packaging.
It's not that simple. The compiler can do stuff that the builder knows
nothing about.
e.g. you have module A, called by module B, C and D.
The compiler can take functions from module A, and to save the overhead
of a function call it can inline pieces of code from A into B, C and D.
Then you make an internal change to A. No code changes to B, C and D.
However, maybe the changes mean the code can no longer be inlined into
other modules. So you only changed A, but also need to ship B, C, D.
It's also possible that the changes to B, C, D also affected other
modules that call them (e.g. maybe they inlined the B code that inlined
the A code).
Maybe you then make a seemingly unrelated change to module F, but that
affects the compiler heuristics about what should be inlined (e.g.
module size) and inlining of A, B, C, D changes again.
To develop correct SMP requisites you need to know not only what you
changed, but also track whether any other related modules have
consequential changes to the *output* from the compiler - not just their
source code.
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
