Aristos Queue Posted June 29, 2012 Report Share Posted June 29, 2012 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 comment Share on other sites More sharing options...
Aristos Queue Posted June 29, 2012 Author Report Share Posted June 29, 2012 (My current best idea is to put all the DLLs into the source and then have a post-install action that deletes the unused ones and moves the used one into the position where the code expects to find it. I haven't tested the order of mass compile vis-a-vis the post-install VI.) Link to comment Share on other sites More sharing options...
Michael Aivaliotis Posted June 30, 2012 Report Share Posted June 30, 2012 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 comment Share on other sites More sharing options...
RolfK Posted July 31, 2012 Report Share Posted July 31, 2012 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.