Jump to content

Openg & LAVA CR seperate source & compile ?


Recommended Posts

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

Link to comment

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.

Link to comment

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

Link to comment

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?

Link to comment

Join the conversation

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

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

×
×
  • Create New...

Important Information

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