Skip to main content

OCAP-RI library naming convention

2 replies [Last post]
amirn
Offline
Joined: 2009-05-06
Points: 0

Hi,

Is there any reason why OCAP-RI no longer use "_g" to differentiate between debug and production shared libraries?

In my opinion this was an unnecessary change.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
greg80303
Offline
Joined: 2008-07-03
Points: 0

The reason for this change was sent out to the "dev" and "users" mailing lists. Please subscribe to these lists for important information about changes to the system.

The change was made because of requests that we received to always build the "optimized" or "non-debug" JVM binaries by default -- large, complex applications were taking too long to load. However, we still want to build the stack libraries in "debug" so that we can do development-related debugging. With the old setup, when the JVM was built with debugging enabled, it only looked for JNI libraries with an "_g" suffix. If the JVM was built with debugging disabled, it only loaded JNI libs without the "_g".

Since much of the JNI code that the JVM relies on is part of the stack build (libmpe.dll), we would have had to rename these DLLs anyway or introduce a step in the build process that creates a copy of the library with the "_g" suffix. The stack already has its own organizational structure for separating debug/release binaries, so we just got rid of the JVM-introduced "_g" policy.

G

amirn
Offline
Joined: 2009-05-06
Points: 0

That makes sense now. Thanks.