topic Re: separate compiled code from source, no effect? in LabVIEW

separate compiled code from source, no effect?

thutch79 — Tue, 22 Oct 2013 19:55:56 GMT

We use SVN for source control of our Labview code. I recently created a VI that goes through our entire labview project and selects the "separate compiled code from source" option on every VI. I thought this would prevent unnecessary requests to save VI's that have been affected by a change to a subvi. However, it has not had any effect. If anything, I believe it's worst. Has anyone else had this experience?

Re: separate compiled code from source, no effect?

Hooovahh — Tue, 22 Oct 2013 20:14:10 GMT

I also changed our repositories to not include compiled code. Now when we change a type def control we no longer have to resave all the VIs it references. This is good for source code control because obviously only the files changed get pushed. Are you saying after making the change to have all VIs seperate compiled code, that the behavior is not the same as I described?

Re: separate compiled code from source, no effect?

thutch79 — Tue, 22 Oct 2013 20:25:18 GMT

Yes I am. I've selected the check box on each VI to seperate compiled code, and it still asks to save many, many unnecessary files. In fact, I think it's worst.

This is LV 2012, sp1 f5, by the way.

Re: separate compiled code from source, no effect?

thutch79 — Tue, 22 Oct 2013 20:26:47 GMT

Is it necessary to do a mass compile after the switch? I wouldn't think so, since flipping the switch required me to save each VI at that time.

Re: separate compiled code from source, no effect?

Hooovahh — Tue, 22 Oct 2013 20:29:01 GMT

It's been a while but I believe this was the tool I used:

https://decibel.ni.com/content/docs/DOC-20926

And afterwords I didn't have to mass compile. I assume because like you said the save will force a recompile anyway.

Re: separate compiled code from source, no effect?

thutch79 — Tue, 22 Oct 2013 20:48:48 GMT

Thanks, I haven't seen that tool. I made my own. How I got them all converted is probably irrelavent, right? If I go through all my VI's, they all now have the check box enabled. The problem is it isn't acting as advertised after that change was made.

Re: separate compiled code from source, no effect?

Hooovahh — Tue, 22 Oct 2013 20:49:58 GMT

Yeah the method likely doesn't matter, not sure why it isn't working right.

Re: separate compiled code from source, no effect?

thutch79 — Tue, 22 Oct 2013 20:58:41 GMT

In looking further, many of the VI's it wants to save all use the same enum. I have recently made a change to that enum. I thought this would prevent the save request when something like that happens. Am I not right?

Re: separate compiled code from source, no effect?

altenbach — Tue, 22 Oct 2013 22:07:27 GMT

Is the enum (*.ctl) file also set to separate compiled code? Just wondering....

Re: separate compiled code from source, no effect?

thutch79 — Wed, 23 Oct 2013 12:04:27 GMT

Yes, the enum is a type def with the "seperate code" option selected.

Re: separate compiled code from source, no effect?

crossrulz — Wed, 23 Oct 2013 12:13:20 GMT

If memory serves, I had to force a compile at least once before the separate took effect. The mass compile did it for me when I made that change on a project to separate compiled.

Re: separate compiled code from source, no effect?

thutch79 — Wed, 23 Oct 2013 12:33:12 GMT

Worth a try. Thanks. I will have to wait until a good time to be able to check in all files to SVN again. I'll report back when I've tried it.

Re: separate compiled code from source, no effect?

Joseph_Loo — Wed, 23 Oct 2013 13:07:11 GMT

Have you tried to place your items in a project and use the project property to set compile source as separate. It seems to work for me without problems.

Re: separate compiled code from source, no effect?

thutch79 — Wed, 23 Oct 2013 15:37:19 GMT

Huh....I tried looking for a global setting on the project in the past. I never knew that was there. I will try that after our next SVN branch merge.

Re: separate compiled code from source, no effect?

MikeBowen — Thu, 05 Dec 2013 15:29:45 GMT

I am in the process of running your tool. Will let you know how it works. What prompted it for me is that an instrument class I was working on has one of the files show up as modified when I open it, and it is one of a very long list. This beats opening them all up and checking them by hand, and I couldn't figure out how to check it programmatically. I will get around to figuring it out, eventually. 🙂

Mike

Re: separate compiled code from source, no effect?

thutch79 — Thu, 05 Dec 2013 16:14:13 GMT

I have now setup my project so all VIs, class, controls, etc all have seperated compiled code. Also all new items created will have seperated compiled code. I've mass compiled everything. From my experience, it has absolutely no effect. Anytime I change a subvi, any VI that calls it wants to be saved as well. Maybe I don't have a good understanding of how this should work, but I thought it was to prevent unnecessary save requests, right?

In the mean time, I've also moved to LV 2013. It doesn't seem to help in 2013 either.

Re: separate compiled code from source, no effect?

altenbach — Thu, 05 Dec 2013 16:22:42 GMT

@thutch79 wrote:

I have now setup my project so all VIs, class, controls, etc all have seperated compiled code. Also all new items created will have seperated compiled code. I've mass compiled everything. From my experience, it has absolutely no effect. Anytime I change a subvi, any VI that calls it wants to be saved as well. Maybe I don't have a good understanding of how this should work, but I thought it was to prevent unnecessary save requests, right?

What are you actually changing in the subVI?

If you change the code of the subVI, no changes need to be made to the caller. if you change the name of the subVI, the caller needs to be updated, of course.

(not sure what happens for inlined subVIs...)

Re: separate compiled code from source, no effect?

JÞB — Thu, 05 Dec 2013 16:43:07 GMT

To follow up and expand on Christian's points.

Some changes to a sub-vi will always require a recompile of the caller. Some of these are obvious if you really think about it, some are not so obvious. But, if you break the interface to the caller (the connector pane) you will need to resave the caller

Datatype change to a wired input terminal that is not dynamic dispatch (you really can't change the datatype of a DD terminal)
Direction change to a wired input
Connector Pane pattern change
Recomended or optional terminals marked as required
Change to a wired enum type def
Change to which terminal is dynamic dispatch

This list is not necessarilly complete

Re: separate compiled code from source, no effect?

thutch79 — Thu, 05 Dec 2013 18:42:02 GMT

I haven't paid too much attention to what's changing versus what callers require saving. I'm sure it's my understanding of the feature that is lacking. Thanks for the list.....that's helpful.

Re: separate compiled code from source, no effect?

Garvacious — Thu, 23 Jan 2014 19:54:48 GMT

I too am disappointed- I was hoping that enum typedef changes would stop trying to recompile everything that called them. I guess this cannot be prevented- not sure why as I assumed that the "source" part of the file only contained the block diagram itself and not the compiled code. Which makes me wonder, what situations WOULD this option prevent LabVIEW from recompiling files that were not physically changed in? The enum typedef propagation was one of my chief frustrations when trying to use LV with source code control.