is there a way to binary diff executables built with the application builder?

[adamol2]

I'm looking for a way to rebuild LabVIEW applications with the application builder and have them match using a diff tool. Our company likes to recompile SW right before release and since the application builder produces a build that won't diff with what's been tested, we have to retest at the end since its a different department recompiling SW for release which I'd like to avoid. 

Any thoughts?

Thanks

Adam

[billko]

---

@adamol2 wrote:

I'm looking for a way to rebuild LabVIEW applications with the application builder and have them match using a diff tool. Our company likes to recompile SW right before release and since the application builder produces a build that won't diff with what's been tested, we have to retest at the end since its a different department recompiling SW for release which I'd like to avoid. 

Any thoughts?

Thanks

Adam

---

My thoughts are:

You'll never have an identical build.  I'm not sure you can end up with an identical build in any progamming language.  To me, rebuilding software right before release is an unnecessary, and even dangerous, step.  Your company recognizes the risk by having you retest the software, but why introduce unnecessary churn?  It's like rebuilding a car's engine right before shipping.

[Zwired1]

One thought is to do a pre- or post-build action VI that exports all of the revs (like you see in VI props>>revision) for the discrete VI's in the project .  You can set it to increment the rev every time the VI is saved. If the revs are the same you know nothing has changed but if they're different you won't know if the thing that's changed is significant. 

Another thought is maybe TortoiseSVN or similar could keep track of what's-changed-and-why for you but I've never use it.  

[billko]

---

@Zwired1 wrote:

One thought is to do a pre- or post-build action VI that exports all of the revs (like you see in VI props>>revision) for the discrete VI's in the project .  You can set it to increment the rev every time the VI is saved. If the revs are the same you know nothing has changed but if they're different you won't know if the thing that's changed is significant. 

Another thought is maybe TortoiseSVN or similar could keep track of what's-changed-and-why for you but I've never use it.  

---

While that would serve the purpose of showing that the source hasn't changed (although I'm not so sure that relying onrev numbers is the best way to go about it - CRC check per file is probably better), it still doesn't gurantee that the build works.

I just think that the whole process probably burns up several thousand dollars worth of unnecessary testing, V&V and paperwork.

[Zwired1]

Agreed on all counts. 

It's weird, 'cause in the past QA has always been known for being the most logical, cost effective organization.....