Should libraries separate compiled code from source?

[JKSH]

Hi all,

 

I know that separating compiled code from source is good for a project that's in development, as it avoids the need to re-save every other VI in the project after one small change. That makes source control much saner.

 

What about code libraries that are distributed to other developers though (e.g. through VIPM)? The user of the library wouldn't (shouldn't) modify the library VIs, so the previous reasoning no longer applies. Is there a good reason to enforce separation (or enforce non-separation)?

[LogMAN]

The only reason to separate compiled code in the first place is to reduce the file size and prevent incidental file-changes for code under SCC. I think everyone working with the 'separated compiled code' option had to clear the Compiled Object Cache once or twice. So from that point of view there is really no reason to keep compiled code separated, it might acually cause issues where the developer has to clear the object cache to make the VIs work again.

 

That being said, all VIs in my libraries have their compiled code separated... I actually have never given this much thought.

[Yair]

One good reason to separate is that recompiles still happen in released code (change platform/bitness/version etc.) and if you don't separate, LV will show your VIs as modified unless the installer resaved them after install (which VIPM is supposed to do if it's configured to, but didn't always work). There are also cases where VIs occasionally decide they need to recompile for no apparent reason (VIs which have ActiveX calls are particularly bad at this - they decide they have a different component from the one they had before).