Leaderboard

I've been using "separate compiled code" in 2012 for some time, and for the most part it works without a problem. The only thing I recall is getting out of sync with an RT deployment, but clearing the cache and starting over got things working. One point not yet mentioned is that it's also very useful for code that is used in both 32 and 64-bit LabVIEW.

Hmm, for me, to the contrary everything has worked without a hitch since unseparating source for that particular project-- it solved the deployment problem I was having. It was in 2014 too. I have a feeling cause hiccups when you have dependencies shared by both the windows target and the real time target- for example you have a class that works on the RT side, and a typedef control within that class that gets used somewhere on the windows/HMI side. That's a no-no, disconnect from typedef always if you have too. I don't have conclusive evidence to back it up though. I wish I had a clearer picture on how the whole dependencies / multiple targets / compiling worked to better understand why things like this might happen

I'll add to this case: project currently contains ~3000 VIs and ~300 classes. The code, written in LV2013, is shared between PC and RT PXI target. We've separated compiled code when the project already contained significant amount of code. The reason for this was irritation whenever someone tried to commit some minor changes into SVN, but found out that this minor change triggered changes to half of the project hierarchy. It was especially problematic when 3 people was making some heavy developmement on different modules and LV decided that it should recompile some libraries that didn't even had any apparent connections to each other (well, I think there are few to none people in the world currently who fully understand the ways of LV compiler ;P ). So we've separated code. I don't have any solid metrics to it, but we've concluded that our commits became clearer and number of conflicts dropped (ok, there is one metric - number of "wtf is this VI that is marked changed? I swear I've never even known it existed" dropped drastically). Now for the most interesting thing: the effects on deployments and builds. We have absolutely no evidence or even feelings that separation has made anything worse. By this I mean the deployments to RT were just as buggy, unreliable and painful as before separation, but not more. I remember at some point we've even tried to reattach the code (of course, with whole cache clearing, recompilation, etc) to check whether it would help with deployments and it didn't help at all. As far as I remember, we've even reverted the repo to the point before separation and first thing we saw when tried to run the code on RT was "Deployment completed with errors" You're absolutely right about problems in versions before 2013. I know from my collegues that they tried it in 2011 or 2012 in smaller project and failed. Summing-up: code separation seems to be very convenient for the team developement (but as I said - I have no metrics, just the general overview of changes commited to repos and feelings in the team). The deployments and builds of code which is shared between different targets are just generally broken, they don't seem to be more broken with compiled code separation as of LV2013. The apparent deployments fix when reattaching the code is probably just due to some recompilation happening in the process and is not connected directly to this option.