LabVIEW
separate compiled code from source, no effect?
@Garvacious wrote:
Which makes me wonder, what situations WOULD this option prevent LabVIEW from recompiling files that were not physically changed in?
Be careful with your terminology. With the separate compiled code, all object files (compiled code) are saved in some repository that NI keeps track of. Any changes to other files will cause a VI to be recompiled. But that does not necessarily mean your source file will be changed.
For instance, A calls B. Somebody goes into B and changes something. A will still need to be recompiled. But with the separate compiled code, the source file a A will not change. This helps so much with source control.
OK, I did verify (by looking at a related thread) that as of LV2012, NI is forcing typedef changes to update all their callers' .vi files regardless of the "separate source code" setting due to a bug with the feature in LV2011. Glad they fixed the bug but this takes away (for me at least) the chief use case for this option and makes it much less useful. Sure, there are other cases where separating source code would prevent lots of unnecessary .vi changes but the typedef propagation is by far the biggest offender.
For those of you who have never done a large multideveloper project with source code control- you have no idea how frustrating it is to change one vi and have 50 other files suddenly want to commit changes to your source code repository. It makes organzied development and change tracking very, very painful. The bigger the project the worse this gets.
And crossrulz- what I was referring to (although I admit my terminology was wrong) was that my .vi source files are still getting "dirty dots" even with the separate source code option selected. I just found out why (see explanation above).
Garvacious wrote:
For those of you who have never done a large multideveloper project with source code control- you have no idea how frustrating it is to change one vi and have 50 other files suddenly want to commit changes to your source code repository. It makes organzied development and change tracking very, very painful. The bigger the project the worse this gets.
I have been on those and have experienced it. The separate from compiled code is the perfect fix for exactly what you just described here. Type defs are a totally different story. But you really should not be changing your data structures that far down the developement process. Those should be all but set early on.
@crossrulz wrote:
But you really should not be changing your data structures that far down the developement process. Those should be all but set early on.
In an ideal "textbook" world, sure. But real-world projects often include things like scope creep, sudden requirements changes, "agile" development processes, etc. etc. Typedefs change.
Sorry to revivie an old thread, but I'd love to know if NI has plans to once again tackle the idea of preventing typedef changes from immediately recompiling every vi that uses the typedef. It does sound like allowing this feature (by way of separating source and object files) caused issues- can it be re-addressed in a future version of LV or is it just too difficult to do given the nature of the LabVIEW compiler?
@Garvacious wrote:
Sorry to revivie an old thread, but I'd love to know if NI has plans to once again tackle the idea of preventing typedef changes from immediately recompiling every vi that uses the typedef. It does sound like allowing this feature (by way of separating source and object files) caused issues- can it be re-addressed in a future version of LV or is it just too difficult to do given the nature of the LabVIEW compiler?
I have been told that NI is looking into the cases that cause this. Supposedly, one of the cases will be fixed in LabVIEW 2014. I haven't tested it in the beta yet to say for sure, so don't take that a golden information.
