Name Mangling of library Members is Optional

The following is a feature change proposal for OpenG Builder 3.0.

Feature Overview
This feature would make name mangling of LVLIB members optional. Currently (in OpenG Builder 2.0) both the LVLIB and its members are name mangled. For example, if a VI is named "foo.lvlib:bar.vi" and get's name mangled with a namespace of "monkey", then:

In OpenG Builder 2.0, it will become:


 * "foo__monkey.lvlib:bar__monkey.vi"

However, if only the LVLIB is name mangled and not the members, then the VI would be name manged as:


 * "foo__monkey.lvlib:bar.vi".

Why this Feature is Important
It is not really necessary to name mangle the VI file name, since name mangling the LVLIB effectively changes the namespace of the VI. Name mangling both the LVLIB and the VI is excessive but doesn't add any extra protection against name collisions.

Also, changing the names of LVLIB members can actually break code for LVCLASS members that are dynamic (override) methods. Since LabVIEW expects dynamic methods in an LVCLASS hierarchy to all have the same name, then name mangling the method VI names can break the dynamic methods -- the overriding will no longer occur. For example, if "parent.lvclass" defines a method called "work.vi" and "child.lvclass" overrides it. Then we start with the following VIs:


 * "parent.lvclass:work.vi"
 * "child.lvclass:work.vi"

If we name mangle the parent.lvclass into the namespace "foo" and the child into the namespace "bar", then we get:


 * "parent__foo.lvclass:work__foo.vi"
 * "child__bar.lvclass:work__bar.vi"

We can see that the method names have been changed, which will break dynamic dispatch. However, if we only name mangle the lvclass and not the methods, then we get:


 * "parent__foo.lvclass:work.vi"
 * "child__bar.lvclass:work.vi"

In this case, dynamic dispatch will work just fine.

Other Requirements
Compatibility with Existing Build Rules (Projects) - In order to remain compatible with users' existing projects, the default value of this parameter for existing build files (*.ogbld or *.deab files) should be TRUE (i.e. NameMangleLibraryMembers=TRUE).

Default Value for New Projects - The preferred behavior is to not name mangle library members. So, for new projects, the default value should be FALSE (i.e. NameMangleLibraryMembers=FALSE)

Technical specification
A discussion document is setup for the technical specification