Reuse PPLs for both 32 and 64 bit LabVIEW

[dblk22vball]

I have watched several of the videos online regarding building PPLs and a plugin architecture, and some of the build issues that have been encountered.   One thing that I havent seen is how to handle both 32 and 64 bit PPLs.

Currently, we have both the 32 and 64 bit versions of LabVIEW on the same PC, and I am running into an issue of how to properly deal with the PPL plugins.  

We distribute the reuse PPLs via VIPM.   

The install process for this is typically:

- When built, Package both bitness into the same VIP file

- Unpack to a temp folder

- Determine the bitness and move the desired bitness PPL to the install folder (Ex: C:\ProgramData\PPL\DB Base\DB Base.lvlibp)

- Delete the temp folder with the "incorrect" bitness.

 

This works when we only have one version of LabVIEW on a PC.   But there may be times when we need both the 32 and 64 bit on a machine, depending on the programs installed.  An example being a test software that needs 64 bit and we would also want another tool that we developed and is in 32 bit, and they both need to use the DB Base.lvlibp.

Having both try to access the same file (C:\ProgramData\PPL\DB Base\DB Base.lvlibp) wont work for one of the bitness'.

Is it better to append the bitness to the file name?  (Ex: C:\ProgramData\PPL\DB Base\DB Base 32 bit.lvlibp)

Or to the folder?  (Ex: C:\ProgramData\PPL\DB Base 32 bit\DB Base.lvlibp)

 

In either case, I can see my build process getting more complicated for the plugin module (DB Plugin), which inherits from the DB Base PPL....

- Do I have a 32 bit project (DB Plugin 32 bit.lvproj) that points to the C:\ProgramData\PPL\DB Base\DB Base 32 bit.lvlibp and a 64 bit project that points to the 64 bit base PPL (or folder)?

[Rolf Kalbermatter]

The only thing I have found to work is to maintain separate projects for 32-bit and 64-bit and have them each build into a seperate location on disk. Anything else is going to mess up your projects almost beyond repair possibilities.

That applies to both the projects to build your PPLs, possibly one project per PPL in the case I worked on, as well as for the applications using those PPLs. Using Symlinks to map the build locations of the PPLs to a common path that is referenced by all the projects making use of PPL dependencies (including PPL build projects), helps with maintenance of the projects as they all only need to reference a general location for dependencies rather than an architecture specific location.

Edited April 16 by Rolf Kalbermatter