The general rule:There should be no need to recompile ABL code between service pack releases/hotfix releases as the r-code will remain unaffected.
The same holds true for procedure libraries, there should be no need to rebuild those.
There are exceptions to these rules, which occur if the r-code structure or contents would change as the result of a bug fix, or if the structure of a procedure library changes as the result of a bug fix. To be more specific:
1. Fixes for bugs in the ABL compiler:The compiler is what builds and writes the .r files, changes in this process usually result in different .r files even if the ABL source code remains the same.
2. Fixes in source code shipped with the OpenEdge product:Usually seen with SmartObjects-based code, or with customized code relying on the ADE Development tools code. If the source code provided by Progress was updated, any code relying on it may need to be updated as well.
This is expeciallly true where include files (.i) are involved, as include files are all handled at compile time.
3. Fixes in built-in classes or compiled classes shipped with the OpenEdge product:If ABL code inherits from one of these, the class signature will have changed and the existing compilations will be out-of-date.
4. Fixes in the prolib tool:This tool is what builds & maintains procedure libraries (.pl) , changes in this usually result in different .pl files even if the .r files contained remains the same.
5. Any changed .r file may require .pl files to be rebuild:This depends on the deployment strategy used:
- For convenience, the updated .r files can be inserted in the propath before the existing .pl files for changes to take effect. The update may or may not be packaged in it's own .pl file.
- For optimal performance, it is recommended to repackage the procedure libraries. This helps keep the propath as short as possible, and the resource usage as low as possible.
