How to build a PPL including Actor classes, messages and AF Debug

[cbutcher]

---

@DoctorAutomatic wrote:

---

@CaseyM wrote:

Yeah, that works. Just wanted to be clear that it was something aware of.

---

Well, I'm back to the drawing board in a sense, after becoming aware of this THIS old thread that I am amazed I only recently became aware of. I recently tried to bring a 32bit project up to 64bit and realized this issue. Seems I should be building things like AF PPL to vi.lib. Is my understanding wrong with regards to the linked thread? Obviously this will only be an issue for anyone who's porting a project that's dependent on a PPL, between targets (in my case 32bit >> x64).

---

Solving this problem is why I rearranged my directory structure for PPLs slightly from my initial attempt (note, that almost every post/presentation I've given on this topic uses the 'newer' style).

Initially:
C:\LabVIEW Sources\PPLs\<awesome ppl>.lvlibp

C:\LabVIEW Sources\<my project b>\project_b.lvproj (depending on PPLs at "..\PPLs\<awesome ppl>.lvlibp)

Now, and relating to your problem switching 32/64-bit:

C:\LabVIEW Sources\PPLs\Windows\Release_32\<awesome ppl>.lvlibp

C:\LabVIEW Sources\PPLs\Current -> C:\LabVIEW Sources\PPLs\Windows\Release_32 (or Debug_32, or Release_64, or whatever you need)

C:\LabVIEW Sources\<my project b>\project_b.lvproj (depending on PPLs at "..\PPLs\Current\<awesome ppl>.lvlibp)

This allows moving a directory junction (mklink /J <link> <target>) to switch between bitness or rel/debug.

Note that (at least as of the versions I tested) a symbolic link (mklink /D) is not suitable, it must be a "directory junction" (on Windows).

I tried to make the linked thread work for me (it would be amazing...) but I couldn't get it work correctly (i.e. at all...) with my cRIO-9045 PPLs.

Currently my build system can clone the source for a library, set the directory junction and install the PPLs required (using NIPM), then build (including for cRIO) by setting Current to point to different locations (for the cRIO, to cRIO-9045/Release or whatever).

Spoiler

Minor embarrassing point - actually I point to cRIO-9045/Release_32 (not 64, oops) because I can only build with LabVIEW 32-bit for cRIO and mixed that up... but the target is actually 64-bit!

Note the downside here is that all libraries must match (i.e. I can't switch only some to debug and keep others at release versions, at least without manually messing up my files via copy-paste messing around - but I could do that in a new directory like C:\LabVIEW Sources\PPLs\Windows\My Arbitrary Mash\<pplA>.lvlibp (release) and <pplB>.lvlibp (debug).

[DoctorAutomatic]

---

@cbutcher wrote:

---

@DoctorAutomatic wrote:

---

@CaseyM wrote:

Yeah, that works. Just wanted to be clear that it was something aware of.

---

Well, I'm back to the drawing board in a sense, after becoming aware of this THIS old thread that I am amazed I only recently became aware of. I recently tried to bring a 32bit project up to 64bit and realized this issue. Seems I should be building things like AF PPL to vi.lib. Is my understanding wrong with regards to the linked thread? Obviously this will only be an issue for anyone who's porting a project that's dependent on a PPL, between targets (in my case 32bit >> x64).

---

Solving this problem is why I rearranged my directory structure for PPLs slightly from my initial attempt (note, that almost every post/presentation I've given on this topic uses the 'newer' style).

Initially:
C:\LabVIEW Sources\PPLs\<awesome ppl>.lvlibp

C:\LabVIEW Sources\<my project b>\project_b.lvproj (depending on PPLs at "..\PPLs\<awesome ppl>.lvlibp)

Now, and relating to your problem switching 32/64-bit:

C:\LabVIEW Sources\PPLs\Windows\Release_32\<awesome ppl>.lvlibp

C:\LabVIEW Sources\PPLs\Current -> C:\LabVIEW Sources\PPLs\Windows\Release_32 (or Debug_32, or Release_64, or whatever you need)

C:\LabVIEW Sources\<my project b>\project_b.lvproj (depending on PPLs at "..\PPLs\Current\<awesome ppl>.lvlibp)

This allows moving a directory junction (mklink /J <link> <target>) to switch between bitness or rel/debug.

Note that (at least as of the versions I tested) a symbolic link (mklink /D) is not suitable, it must be a "directory junction" (on Windows).

I tried to make the linked thread work for me (it would be amazing...) but I couldn't get it work correctly (i.e. at all...) with my cRIO-9045 PPLs.

Currently my build system can clone the source for a library, set the directory junction and install the PPLs required (using NIPM), then build (including for cRIO) by setting Current to point to different locations (for the cRIO, to cRIO-9045/Release or whatever).

Spoiler

Minor embarrassing point - actually I point to cRIO-9045/Release_32 (not 64, oops) because I can only build with LabVIEW 32-bit for cRIO and mixed that up... but the target is actually 64-bit!

Note the downside here is that all libraries must match (i.e. I can't switch only some to debug and keep others at release versions, at least without manually messing up my files via copy-paste messing around - but I could do that in a new directory like C:\LabVIEW Sources\PPLs\Windows\My Arbitrary Mash\<pplA>.lvlibp (release) and <pplB>.lvlibp (debug).

---

It's going to take me a bit to "chew" on everything you wrote but it did bring up a point that I sort of let slip in the background and haven't revisited.

Back when I first made an AF PPL I simply added AF Debug to it thinking I might want it later on and thinking "how harmful could it possibly be to just include it?". It's been completely out of mind since. So my question is, is it worth it to compile more AF PPLs variants, with/without AF Debug, in addition to 32bit/64bit, etc.?

[CaseyM]

Similar to @cbuther's solution, @IlluminatedG had a clever solution also involving symbolic links (directory junctions). Take the following example:

C:\Source\Windows Target.lvproj

C:\Windows\PPLs\[your Windows PPLs]

C:\Windows\Source [a symbolic link to C:\Source]

C:\Source\Linus RT Target.lvproj

C:\Linux RT\PPLs\[your Linux RT PPLs]

C:\Linux RT\Source [a symbolic link to C:\Source]

If you open "Windows Target.lvproj" from C:\Windows\Source, the relative path to the PPLs will be "..\..\PPLs\" and if you open "Linux RT Target.lvproj" from C:\Linux RT\Source, the relative path will to the PPLs will also be "..\..\PPLs\" - same relative path, but reliant on two different PPL build outputs. The (somewhat) obvious catch here is that you need to open the proper project from the proper directory.

This example uses different targets but the same idea can be applied to different bitnesses.

If you're not switching between bitnesses/targets and the issue is just that you want to update to 64-bit from 32-bit, what's stopping you from rebuilding the necessary PPLs?

[IlluminatedG]

That's on my list of tooling to recreate...