Allow separating debug information from a PPL to a complementary file

[cbutcher]

Summary: I'd like to be able to build a PPL build-spec and get two files, "myLibrary.lvlibp" and "myLibrary-debug.lvlibp" (or maybe myLibrary.lvlibp-debug?), where colocation of the second file allows debugging use, but distribution of the first is sufficient to run without debugging tools.

Longer description/explanation/motivation:

When we build Packed Project Libraries (PPLs) we can choose to include or remove debugging information.

Without the debugging information, we have an optimized-for-deployment PPL that has smaller size, perhaps faster performance/loading, etc.

With debugging information, we can debug in the development environment.

In order for these to be used in place of one-another, they must have the same name, and the expected location. That is, if I write code on my dev machine using the debug libraries, I must replace those with the release PPLs (or exclude them from any builds, a common option) and then copy the release versions. I must rely on things like location (or worse, file size) to determine which is rel/debug, or rename into location, and then handle these 'manually' in my build processes.

Further, if I want to build nipkg files containing lvlibp files, determining appropriate dependency management when there are alternative packages for each library, but they can be independently interchanged (e.g. for A->B->C, I can have A-debug -> B-release -> C-debug if I want, or A-rel -> B-rel -> C-rel), is as far I can tell impossible. This is in part due to the Debian packaging format, which does not have a concept of a preferred dependency (such that I could choose to make "release" packages prefer "release" dependencies, but accept "debug" too). The behaviour at install time is not defined (you can get either, based on unspecified and to me unknown details).

Debian packages handle this by providing a "myLibrary" package, and a "myLibrary-dbg" package, containing e.g. debugging symbols (but NOT the code required for the library to work - so a dbg package always(?) depends on the non-dbg version of the same package).

I'd like this to be possible with LabVIEW, which seemingly would require the ability to load debugging information from a secondary file.

If LabVIEW allowed the dev environment to preferentially (and silently) load "myLibrary.lvlibp-dbg" in place of "myLibrary.lvlibp", then changes to build time are still desirable, but no longer required - in that case we can simply put both files (debug, release versions) in the same directory with different names and choose which to deploy (ideally LabVIEW would also deploy the release versions (unmodified names) during e.g. executable builds). This costs some extra disk space, since the debug package is a superset of the release package, but disk space is cheap and NI engineering time presumably less so...

[wiebe@CARYA]

That could also apply to executables?

Iff this was possible for plls it should be possible (and neat) for executables.

Spoiler

I very much doubt it is possible, as things are simply removed when debugging is off. So actually code that triggers debugging signals is removed from the code. No external source would be able to 'insert' those triggers.

It would boil down to all compiled code in the ppl, a cpoy of the copiled code in the ppl-debug.

[cbutcher]

If it could work for executables, that would also be nice.

Re the spoiler, if splitting the library is considered too technically expensive/impossible to implement, then the backup 'silently and automatically load debug libraries with a fixed-pattern different name from the same directory, and store references to the non-debug name' (last paragraph) is fine as a second choice for me.