Update on typedef triggering re-compilation in LV2012

[CharlesB64]

Hi there,

More than one year ago I raised a problem about a new feature in LV 2012, that is triggering file changes to all VIs that make use of a typedef if the latter has changes.

This is a stopping problem for us, since it makes source control commits potentially huge if there are a numerous VIs that use the changing typedef, which means it's a lot more difficult to identify what are the real changes in a commit.

I'm still stuck to LV 2011, which is OK for now. I have dozens of typedefs, and changing each one of them to a class seems really overkill to me. I will have to move on sooner or later...

So I'd like to know if people have

* made the move without change, accepting the trouble I mention?

* chose to stay on 2011?

* moved their typedefs to classes?

Also, have NI devs considered workarounds or alternatives to this problem, since the thread had a number of people complaining about impact of this change?

[kegghead]

I have begrudgingly accepted the reality. I still use typedef, but try to keep them reasonably scoped as not to become prolific, most public types are now classes.

There's an unfortunate side effect of the behavior though. Sometimes LabVIEW becomes absolutely convinced a type definition was modified when it has not, and can trigger modifications to hundreds of VIs in our projects. As a result, we have adopted three very painful use guidelines for LabVIEW which frankly have me counting the days until this sorts out or I don't have to use LabVIEW for large application development.

1) Component development is only ever done on a single machine because the simple act of committing on one machine and checking out on another can trigger modified type definitions. Maybe it's a bug, maybe it's real, but either way LabVIEW provides no details other than a laundry list of affected VIs. You do not know pain until you program LabVIEW through multiple layers of virtual machine and VPN.

2) Component and reuse libraries are distributed as packages through VIPM. I hate this solution but it hides a lot of our source code out from SCC. Once a revision is installed to vi.lib or what not, it can change as often as it wants. But now updating a library is outside the scope of SCC: the author makes changes and builds, checks the code in, publishes the binary, informs others who pull it down. Dependencies are documented. Terrible but it has helped tame this beast a bit.

3) Only one developer per component. Ever. I just don't see a way around this. Ugh.

Still need to accept though that within a component, a typedef change (if it is even real) can mess up a whole hierarchy.

[AristosQueue (NI)]

A) In an attempt to improve this behavior, we have had a different behavior for typedefs in LV 2010, 2011, 2012 and 2013. Each change has made some use cases happy and other use cases unhappy, but in 2013, we THINK we have a workable model. This has been quite the roller coaster ride, trying to improve the typedef feature. We haven't gotten nearly the volume of negative feedback for the 2013 model that we have from the first three attempts.

B) If you have a project that demonstrates particularly egregious typedef behavior, particularly if that behavior is still around in LV 2013, R&D would be interested in taking a look. Kegghead, your claims to a typedef that thinks it has been changed when it hasn't would fall in that category. (I use the word "claim" only because we haven't verified it, not to impune your report.) If you can share your code, please contact an application engineer and open a support ticket that will allow that code to escalate to R&D.

[GabbyG]

We are a small consultancy with few heads. Still some projects need more workers than one. As far as I see we restrict typedefs that are globally applicable to very few, that are rarely changed. Modules that have local typedefs and that are worked at by one person are normally kept in lvlibs (Alas, classes are my private pastime). Cross-dependencies I try to mimimize by not using ENUMS to send on queues but Strings, but that is not yet common practice.

We have more updates by hardware related changes or Sub-Vis changes. I try to help this by separating compiled code from source.

And in the end, when 2 TB NAS cost 90 € I do not really care.

Gabi

[jlokanis]

I have a fairly large project with ~260 classes and ~50 typedefs.  I recently tried to move it to a second dev machine.  Identical LV version, same OpenG packages installed from VIPM, exact same disk layout.

When I open the project, 100's of VIs want to be saved.  the resons given seem to vary between:

"The master copy of a Type Definition (or Strict Type Definition) used by this VI was modified."

"The VI's name was changed outside of LabVIEW, or one of its subVIs was found in a different directory."

Any ideas on how to mitigate this?

-John

[David_Staab]

jlokanis wrote:

Any ideas on how to mitigate this?

Develop your code in a virtual machine and share that with other devs.

[jlokanis]

I am the only dev.  I am building a client-server system.  I startd by doing all the work on a single machine and running two projects, one for the client and one for the server.  I wanted to test the client-server connection over a actual network so I build a VM machine, installed LV and my source code on it and tried to open the code.

The code runs fine, it just wants to save a ton of VIs for no good reason.

[David_Staab]

Well that's what you get for running your source code on a different system! Generate a binary and run that, or if you have to debug, make all your edits on the primary dev machine instead of committing changes to the repo from another machine. It's so easy!

[jlokanis]

I gave up on SCC when I started using LVOOP.  The level of file change was just so high that it was not worth it.  Once my code base is settled and I move to a maintenence phase, I will put everything back into SCC.  For now, I just zip and copy to the network for safe keeping.

I do want to keep everything at the source level for now.  I have not reached a point where I can build either app into an EXE yet.  And I am still debugging many features in both applications as well.  I just want to understand why LV thinks I changed a typedef.  What is the secret sauce that triggers this and how can I get it to belive that there is no real change.

I think NI needs to publish the decision tree that it goes through to decide a typedef changed.

At the very least, they could tell me WHICH type def or sub-vi is the culprit triggering the change.  Is that so much to ask?

[David_Staab]

jlokanis wrote:

I gave up on SCC when I started using LVOOP.  The level of file change was just so high that it was not worth it.

Funny, I saw the same problem and arrived at the opposite conclusion: I gave up on LVOOP when I realized the necessity of SCC (and when I realized other issues caused by using Project Libraries).