Andrew, That kind of HLL optimization effect can only happen in a monolithic program where all of A, B, C, etc. sources are available to the compiler at the same time. Developing in modular, separately-compiled programs (whether they wind up in DLL's or just as separately loaded executables) is a different world entirely.
Unfortunately the implementation of C/C++ (and to a certain extent Java) IDE's and build systems (like *ix make and its imitators) tends to make developers think and develop in that "monolithic" mindset, which isn't necessarily the most maintainable way to write and support application code. Just my $0.02USD. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Rowley Sent: Thursday, December 7, 2017 5:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SFTP 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. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
