At the moment, it looks like the COMPILE statement will always output a different .R file, even if the source .p has not changed. It is most likely including some form of datetime stamp or something in the file contents.
Is it possible to setup the COMPILE statement such that it will always produce the same .R file if the source .p has not changed?
This would be useful, especially when generating a patch or similar for an application. We could compile 1.1 and 1.2 of the entire code base, and then only ship those .R files that have changed. At the moment, a basic file comparison detects that every .R file has changed.
OpenEdge has a built in method for that.
If you use the GENERATE-MD5 option of the compile, statement, the RCODE-INFO handle allows you to query the MD5-VALUE for every individual RCODE.
Typically, you'd store the MD5-VALUE's for all RCODE's of one release and compare them to the next release.
The MD5-VALUE changes when the source is changes, any include, referenced classes, a DB table's CRC, etc....
OpenEdge has a built in method for that.
If you use the GENERATE-MD5 option of the compile, statement, the RCODE-INFO handle allows you to query the MD5-VALUE for every individual RCODE.
Typically, you'd store the MD5-VALUE's for all RCODE's of one release and compare them to the next release.
The MD5-VALUE changes when the source is changes, any include, referenced classes, a DB table's CRC, etc....
Ah, thanks Mike, that will help quite a lot. It's a pity that it doesn't change based on whether the pre-processed version of the source code changes, though ie if a &global-define in an include changes, but the source .p doesn't use it, the MD5 should be the same.
I agree that this has been a minor pain. I suspect that very few third-party deployment tools would know how to run "GENERATE-MD5" on an r-code file. And Progress doesn't have its own tooling for doing this stuff (nor for the compilation of the whole app in the first place, come to think of it).
We use robocopy-based commands to copy our application to the deployment target(s). This would be much faster if it didn't think that the entire 2 GB of application r-code files (many thousands) were needing to be refreshed.
Of course there are other things we can do to mitigate: upgrading to 10Gbit network and breaking up the compilation unit into even smaller parts (smaller Eclipse projects) that are only deployed as need.
We used vbvers.i to indetify the .r version.
Example:
Program xxtest.p:
DEF VAR myvers AS CHAR INIT "@(#)1.2".
display "HEllo".
----
COMPILE xxtest.p SAVE
-----
From UNIX:
what xxtest.r
xxtest.r:
1.2
1.2
--------