separate compilation in LV12

[robmacl]

I just upgraded from LV11 SP1 to LV12, and I'm having the impression that something has come unglued with separate compilation.  LV12 seems to be going berserk modifying the .vi files when I haven't (directly) touched anything in that VI.   For one thing, it seems to be very aggressively converting files from LV11 to LV12 format, which results in many spurious file modifications.  Also, it seems that once It's in LV12 format, it's still not satisfied.  It's going back and modifying those files again, even though a code comparison shows (LVcompare) shows no differences at all.  I upgraded two days ago, and over 200 VIs have been marked as modified.  This is not source control freindly behavior.

One thing I was noticing yesterday is that when I change a strict type def that is referenced by many VIs, LV12 seems to have gone back to the old pre-separate compilation behavior of considering all the referencing VIs to be modified.  I do apply changes and save all, and boom, 46 VIs get modified.  I'm sure that someone had some reason for doing this, but it's making me nostalgic for the glory days of LV11.

Can someone at least reassure me that this will settle down eventually, and that LV12 will be done marking its territory with invisible bit excretions?

  Rob

[dkfire]

I can just say one thing, when upgrading from one LabVIEW version to another, LabVIEW needs to recompile all your file to the new version. There is nothing strange about that.

Having 200 modified files duing an upgrade of your development system is not much, and it shouldn't have any complication on your source control system. Just check-in the files after LabVIEW has recompiled the files.

Why did you upgrade LabVIEW in the first place?

Are you sure that your LabVIEW 2012 installation is set up to seperate compile code from vi ?

Settings from the old version of LabVIEW is not transfered to the new version.

[robmacl]

>Why did you upgrade LabVIEW in the first place?

A fine question that is.  Though one I wouldn't expect NI wants their customers to ask.  I guess the short answer is that my experience with upgrades has mostly been positive, since (for example) they added features like separate compilation that made my life easier, and didn't break anything major.  I did have to fix my code in one place when they changed to the LLVM compilar back end, but that was clearly a bug in my code which just hadn't appeared before.  My experience with this upgrade is not so good, and did find at one point that there was an upgrade that I missed where my code basically didn't work (it was copying a multi-megabyte array in a shift register every time around a 2 kHz realtime loop.)  So maybe I've just been lucky up to now.  And the problems I'm having are basically annoyances, loss of features that had been working.  I am using both real-time and FPGA toolkits, which are under active development by NI.

>I can just say one thing, when upgrading from one LabVIEW version to another, LabVIEW needs to recompile all your file to the new version.

Why?  It can read the file in the old format every time until I get around to modifying it.  I'm pretty sure that I have seen LV do this in the past.  My impression is that in LV12 for some reason they really wanted all of the VIs converted right away.

>Having 200 modified files duing an upgrade of your development system is not much, and it shouldn't have any complication on your source control system. Just >check-in the files after LabVIEW has recompiled the files.

Not!  What if I was on a branch?  Well, actually I am, but I'm lucky because there isn't any other concurrent development at the moment.  But the situation is that source control thinks I've changed 200 files that I actually haven't changed at all.  If LV had just left them alone in the old format, the semantics would have been the same (so far as I can tell.  Perhaps there is some good reason why they're pushing this format change, but I haven't heard it.)

Also, I'm seeing this behavior that LV is continuing to make gratuitous modifications to the VI files even after it has changed the version.  When it changes the version, LVcompare says that the VI version has changed.  I'm now in the situation where I have many many modified files where LVcompare reports no difference at all.  It seems like a minimum requirement for source control that you not make changes that your comparison tool can't detect.

>Are you sure that your LabVIEW 2012 installation is set up to seperate compile code from vi ?

Separate compilation is actually a VI attribute which does seem to have been transferred, though I had to restore the option to create new VIs as separately compiled.  This method of controlling separate compilation isn't ideal, because I keep ending up with files that aren't marked for separate compilation, but it isn't the cause for this problem.

  Rob

[dan_u]

---

robmacl wrote:

One thing I was noticing yesterday is that when I change a strict type def that is referenced by many VIs, LV12 seems to have gone back to the old pre-separate compilation behavior of considering all the referencing VIs to be modified.  I do apply changes and save all, and boom, 46 VIs get modified.  I'm sure that someone had some reason for doing this, but it's making me nostalgic for the glory days of LV11.

---

I also hoped that modifying a (strict) type def will not modify all the VIs using it when separating source code from compiled code. But this doesn't seem to be the case (at least with an enum type def I used).

I guess it's related to the fact that the source code contains all information about the type def. You can always disconnect a type def even if LV can't find it. So the source code must update if the type def does.

[robmacl]

>I also hoped that modifying a (strict) type def will not modify all the VIs using it when separating source code from compiled code.
>But this doesn't seem to be the case (at least with an enum type def I used).

It used to work when separate compilation was first introduced (LV11, I think).  I would modify a strict type def, and the referencing VIs would not get modified.  I'm not sure that it was LV12 that broke it, or that it's now broken under all conditions, but I'm seeing this behavior again in LV12.

  Rob

[dkfire]

There should be a difference between modifying a Strict type def and modifying a type def, as far as I can remember. 

Modifying a type def, will not result in a chang in vi's using the type def, while modifying the strict type def will.

Atleast this is regarding when you have a constant of the strict type def in a vi.

There is a tread somewhere on this matter.

[crossrulz]

---

@dkfire wrote:

There should be a difference between modifying a Strict type def and modifying a type def, as far as I can remember. 

Modifying a type def, will not result in a chang in vi's using the type def, while modifying the strict type def will.

Atleast this is regarding when you have a constant of the strict type def in a vi.

There is a tread somewhere on this matter.

---

I'm thinking the same thing.  The strict type def also defines various properties.  So if it gets updated, all of the VIs that use it will have to update simply because of the properties associated with the strict type def.

[dan_u]

---

@crossrulz wrote:

---

@dkfire wrote:

There should be a difference between modifying a Strict type def and modifying a type def, as far as I can remember. 

Modifying a type def, will not result in a chang in vi's using the type def, while modifying the strict type def will.

Atleast this is regarding when you have a constant of the strict type def in a vi.

There is a tread somewhere on this matter.

---

I'm thinking the same thing.  The strict type def also defines various properties.  So if it gets updated, all of the VIs that use it will have to update simply because of the properties associated with the strict type def.

---

I kind of understand that the source code changes when an enum type def changes (no matter strict or not). Think e.g. of an enum wired to a case structure. Without default case the source code will break. But still, technically the source code is not modified.

Disconnecting a missing (on disk) type def would be a problem, though, if the source code does not update to changes in the type def. But I think that would be acceptable.

I never separated source code and compiled code before LV2012 and was quite disappointed to see the behavior described by Rob. Especially with SCC and several developers on one project it would be great not to get dirty referencing VIs when modifying a type def.

[robmacl]

I've verified that redefining strict type defs did not cause the referencing VI to change in LV11, and I have submitted this as a bug report.  It's obviously a work in progress what it means to have "separate compilation" in labview, but by comparison to ordinary text-based programming languages, what it ideally ought to mean is that the "source code" only contains a "name" for the referenced entities, and so need not be changed (automatically or otherwise) when the semantic associations of that name change in a way that is semantically compatible with that individual reference.  I understand that this is very different from how labview has worked in the past, but it is a much better fit for source control systems. 

I would also say that a minimum invariant that is needed for sane source control is that when a VI is is modified, then the before and after VIs should be different according to the comparison tool.  In LV 12, they are not different (according to the comparison tool.)  Whether this is considered a requirement for the comparison tool or a constraint on invisible piddling in the VI file is something that NI's language designers need to work out.

  Rob

[Craig_]

Information on this can be found in this thread: https://decibel.ni.com/content/thread/15606?tstart=0