Recompile source file for include file change...

rzr

Member
I read a post on MGF Forum sometime ago about a change that was needed in an include file - but modifying this would need recompile of 1000's of other programs that using this include. In their case i think they had some work around solution.

I was thinkning - if there was no work around feasible then .. would'nt it be enough if

1. we modify the include
2. recompile only the handful of *impacted* programs

And then at a later stage - the dba can recompile the full source directory during regular monthly maintainence / schema change.
 
In theory you only would need to re-compile the procedures you have identified that need the "new" logic and compile the rest at a more convenient time. In practice that means that you need to be able to handle that situate correctly.

So the only questions are whether you are able to identify all procedures that need the "new" version of the include and whether you can manage the situation to have software deployed that uses different version of the same piece of logic.

Heavy Regards, RealHeavyDude.
 
In a better world you could have also recompiled everything and then checked the MD5-VALUE attribute on the RCODE-INFO system handle to see if the include resulted in any real changes to the code and therefore requiring test effort.

Unfortunately even an extra space in the include file results in a different MD5-VALUE making it somewhat useless - see this thread on PSDN.

I have created a simple tool that will preprocess a file, remove all irrelevant parts (comments & whitespace) and then MD5-DIGEST this. Unfortunately this is not foolproof when the source contains double quotes that are escaped by doubling the quotes ("""" for example). COMPILE PREPROCESS creates a preprocessed source that does not compile.
 
Some time ago my friend asked me to create some tool that extract from rcodes some interesting informations and save it to .csv file. You can later analyze this file with your custom coded tool.
In your case you can look on files that use your target include and recompile only these. Or you can check CRC, MD5 to see if file is changed from last recompile.
It's for Windows and it's freeware.

It extract:
- path to rcode
- rcode file name
- rcode version
- date of compilation (in local format)
- rcode CRC
- rcode MD5 (If you use in compiler option GENERATE-MD5=yes)

Debug file details (only if you use in compiler option MINIMIZE R-CODE SIZE=no). Always 3 parameters for one file.
- file from which was rcode compiled
- path to previous file
- CRC to previous file

Download and more Info:
http://progress-tools.x10.mx/rinfo.html


Check also "RCode Checker" tool - one of checks is: what files need to be recompiled, if some includes are changed.
 
- rcode CRC
- rcode MD5 (If you use in compiler option GENERATE-MD5=yes)

Thanks for the tip, but (as mentioned in the psdn thread) crc and md5 are both useless for detecting relevant changes. See the results from your tool:

1;c:\temp\;p.r;1005;2011-09-14 22:31:19;5560;489B9E62DC98A41A3F3129D498B4E6AB;p.p^c:\^15074|i.i^c:\^51028|
1;c:\temp\;p.r;1005;2011-09-14 22:32:37;32271;E692AC1CFCDE71CC1115C0619B307539;p.p^c:\^15074|i.i^c:\^48587|

p.p was simply:

Code:
{c:\i.i}

And i.i was simply:

Code:
/* only a comment */

which was then changed for the second compile to:

Code:
/* only a comments */

Since the MD5-VALUE changes for an irrelevant change, its useless (in my case).
 
Back
Top