proposal Openg & LAVA CR seperate source & compile ?

[dannyt]

Just a general though / question and I think this applies to both OpenG & LAVA CR's so I was not quite sure where to put this.

I am working on a LAVA CR package and I intend to separate source & compile code and it had me thinking. What is the general take that people have on the separation of source & compile code issue for new tools or LAVA CR's that a LabVIEW 2010 or newer. I did see a comment, but cannot find it now, for NI that this will sometime in the future become the default setting rather than an option.

As this setting can be do programming, I was also think that maybe this could be a feature request for the VIPM, similar to the mass compile on install setting.

Dannyt

[jgcode]

As for OpenG - that feature would require LabVIEW 2010. The next upgrade of the libraries are for 2009. So this question may pop up in the future (although given the feedback here on LAVA it seems that this feature needs some work).

As for packages in general - end users install a package which contains dist code. They do not check in and out the code etc. I am not sure how this would affect the end user? Would it help with builds? Etc.

I would like to see a discussion of the benefits here.

[dannyt]

As for OpenG - that feature would require LabVIEW 2010. The next upgrade of the libraries are for 2009. So this question may pop up in the future (although given the feedback here on LAVA it seems that this feature needs some work).

OK, I can see that it is for now an irrelevance for OpenG. My personal experience of LabVIEW 2010 & this separation feature is only to the good I must say.

As for packages in general - end users install a package which contains dist code. They do not check in and out the code etc. I am not sure how this would affect the end user? Would it help with builds? Etc.

I would like to see a discussion of the benefits here.

In answer to this part, hopefully developers of packages in general ARE keeping their source code in some sort of SCC, and it is from this they build thier packages. So if they are working in LabVIEW 2010 they will get the benefit for themselves in maintaining that code. It provides no benefit as you say to the end user of the package.

Danny

[Jim Kring]

OK, I can see that it is for now an irrelevance for OpenG. My personal experience of LabVIEW 2010 & this separation feature is only to the good I must say.

In answer to this part, hopefully developers of packages in general ARE keeping their source code in some sort of SCC, and it is from this they build thier packages. So if they are working in LabVIEW 2010 they will get the benefit for themselves in maintaining that code. It provides no benefit as you say to the end user of the package.

Danny

I can see a couple possible benefits to end users:

1) No modifications to installed VIs allows easier validation -- if the installed VIs are never modified (at the installed location), then it's easy to validate that no inadvertent changes have occurred.

2) No modifications to installed VIs when deploying to multiple targets -- when the same VI is used in multiple targets (RT, FPGA, My Computer), then it will show unsaved changes and need to be recompiled each time it is run on the target in question. Keeping the compiled code separate will avoid this.

Any others?

[jgcode]

It provides no benefit as you say to the end user of the package.

No, I was actually saying that I did not know what the benefits are (having not used this feature, nor LabVIEW 2010 a lot).