Jump to content

How to build different platform packages with the same version number?


Recommended Posts

I find myself needing to build platform-specific packages: one for Mac, one for Linux, one for 32-bit Windows, one for 64-bit Windows. I need to change out a DLL between each of these, but I want all of them to otherwise have all the same source settings (palettes, directories, etc) and, ideally, have the same version number.

 

Any advice on how best to build such packages?

Link to post
Share on other sites

I've had this requirement before. I install all the files to the destinations and then create a post-install VI that deletes the files that are not required for that platform. If you use the post-install template VI it will feed you the list of files installed by path. Just do a lookup of the ones you want to delete. This way, if you change the destination in VI package builder, your post-install VI doesn't need to change.

 

Mass compile is a final step. It always runs last after the last package is installed.

Link to post
Share on other sites
  • 1 month later...

I've had this requirement before. I install all the files to the destinations and then create a post-install VI that deletes the files that are not required for that platform. If you use the post-install template VI it will feed you the list of files installed by path. Just do a lookup of the ones you want to delete. This way, if you change the destination in VI package builder, your post-install VI doesn't need to change.

 

Mass compile is a final step. It always runs last after the last package is installed.

 

Actually the OpenG Package Builder does have the possibility to individually apply install conditions to file groups. The only problem there is that it does not yet include 64 Bit selection. Does VIPM support 64 Bit keyword selection in the spec file and how?

 

Ok I checked into that a bit more but haven't made any tests with VIPM so far to see how it behaves. LabVIEW 64 bit returns in the OS.Name property nicely "Windows x64" so it would be easy to distinguish between Windows 32bit and Windows 64 Bit, since the 32 bit version returns "Windows NT" for that property. I'm going to make this small modification to the OpenG Builder to create a test package.

 

The question is only how VIPM has modified the OGPM library! I have a deep suspicion that VIPM is probably manipulating the returned property in order to not fail installation of components that are marked to be installable for Windows NT, when installing them on Windows 64 Bit. This sort of would defeat the purpose of the platform property for file groups, since technically Windows 64 Bit is a completely different platform than Windows 32 Bit.

 

So could one of the VIPM developers comment if the use of the Exclusive_OS="Windows x64" in a file group should work for marking that file group to only be installed on 64 Bit Windows?

 

An additional question: Since VIPM itself is always a 32 Bit executable, this won't work anyhow unless VIPM is executing this OS.Name property in the context of the target LabVIEW system, which is technically possible since that property (and the OS.Version) are remotely accessible according to the LabVIEW help.

 

BTW: The OpenG main page has been spammed again.

Edited by RolfK
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.