Blast From the Past – Same PBL in Different Targets

This PowerBuilder shortcoming popped up again in some emails this week…
The issue – having the same PBL in different targets (all in the same solution).
We first discovered this problem ages ago (even before ‘targets’ existed) – where one PBL is shared between different applications.

The cause of the issue is that the compiled P-Code (stored with the PBL) is dependent on the other PBLs in the target (the code generated depends on its ancestors in the inheritance tree).  IOW – the P-Code became slightly application and environment specific.

The result – sharing that P-Code between different targets, with possibly different ancestors, will lead to difficult/impossible to debug runtime errors. Needless to say, this led to a long history of customer issues…

However – if the ancestors were the same (and same order!), and if all the applications had the same compiler switches, sharing a PBL between targets would work.  Unfortunately, there is that one time where something was changed, and the system would be inconsistent.  This is that difficult/impossible to debug runtime error.

In PB.Net – we wanted to relax this distinction, but we ran into the same code generator issues.  The intermediary code and other cache information is stored in the PBL directory, next to the SR* files (in the ‘obj’ directory) hence locking in a target dependency (sigh).
There was some reason (I don’t remember what) the compiler guys wanted the files in the same directory structure rather than a parallel directory somewhere else (I can imagine a host of housekeeping logistics there, so I can sympathize).

One other thing – PB-Classic would attempt to prevent you from having the same PBL in multiple targets, but its checking was quite imperfect.  This checking was improved in PB.NET (having a fresh slate makes those things easier).

In short – don’t share PBLs between targets.

Advertisements