CRC changes with each build of some projects. Why?

[CoastalMaineBird]

OK, I am officially out of INTELLIGENT ideas.

Here are a few more, take them for what they're worth.

Pick a single project that exhibits this behavior, and completely disconnect it from your version control system.

IOW, have a local copy of ALL files required.

Create a nw BUILD SPEC from scratch and do the minimum required to build the thing.

DUPLICATE that Build Spec.

Build each of those two build specs TWICE.

If Build Spec A produces the same CRC on both EXEs, and Build Spec B produces a DIFFERENT CRC on both EXEs, then it's something to do with your project (Build Spec position).

If ALL FOUR CRCs are the same, it's something to do with your VCS.

If ALL FOUR CRCs are different, it's something to do with the build process itself.

[Bob_Schor]

James,

     For about 95% of my Projects, I am also the "only" developer.  However, when I'm at work, I use my Office PC, when I'm home, I use my Home PC, and when I'm "on the road", I use my Laptop.  I used to tote code back and forth on USB sticks, and almost always got myself in trouble ("Bad, Bob, Bad!!").  It is so much safer and more flexible to "Commit when leaving, Update when starting" and never having to worry about "Is this the latest version?" by using Subversion instead of USB Keys ...

Bob Schor

[billko]

I was always under the impression that the (final) build is the build and it should be done once and only once.  If you have to build it again, it's a different build and needs another build number.  It should not be built every time you need a new copy.  Rather, the executable should be archived.

[jamesbe]

We do archive the executable but also provide instructions on how to build another from the source code. The point of the CRC was like with any other software--to know if what you built/compiled from the source you got is the same as expected.

[CoastalMaineBird]

How are you determining the CRC value of the EXE file?

[tst]

---

@jamesbe wrote:

tst, Do you know how people have been making sure files haven't been modified?

---

No. I have no experience with this and have never had a need for it. Here we simply commit the EXEs and if I rebuild I don't expect the new version to be identical anyway, since then there wouldn't really be a point to rebuilding.

My understanding as an outsider of how the build process works is that LV takes all the VIs and recompiles them with relevant properties and optimizations, saves them all into the build folder as unified files using their relative locations and then converts the resulting folder into a zipped folder which has a small piece of machine code used to load everything. The VIs are then loaded and called exactly as they would be in LV. You can see this process if you look at the build folder using a build. It used to also be possible to look into the zipped EXE, but my understanding is that this was now encrypted.

I'm assuming the saving part is the point at which the VI timestamps change, as Greg points out in the other thread. It might be possible to figure out the structure of the EXE and ignore those timestamps, but I expect it might be easier to verify the source. SVN already does that for you by marking which files have changed. Of course, since source is only half of the equation and an important part of it is the compiled code, which is probably separated, I doubt I would rely on that for a verifiable result.

[billko]

I believe the defense industry has requirements that state that you must have to be able to verify your test station at any given time, and that includes being able to verify that the software you are running is the same software that was released.  At a well-known defense contractor we used MD5 the same way you want to use CRC-32.  The difference is in the actual implementation.  An MD5 checksum is created at the time the software is released and is part of the release itself.  Whenever you needed to verify, you just ran an MD5 check and verified the results.

I have no idea why you would need to verify that a build will come out the same all the time.  In fact, that just has the capability to create a lot of confusion.  Like right now, for instance.  If the method above was good enough for the United States Armed Forces, it's probably good enough for just about any application.

[jamesbe]

To determine the CRC we use a VI that gets put into each VI we build. We also check the CRC using 7zip or WinZip.

When we develop software, we provide the source code and instructions on how to build the executable or hex files. When building the hex files, they are always the same, because the instructions are always the same, no matter what computer they were built on or at what time. 

We do use the CRC to verify that the build the end user has is the build we provided, but we also expected the CRC to be the same if the program was the same. I don't see the confusion in expecting the same code to produce the same file, which is a necessity for embedded systems.

We are discussing just providing the CRCs of the source, and requirements for what packages they need installed on their computer to build them.

If people expect the CRCs of two builds of the same project to be different, could anyone explain why some VI do have the same CRC when built at different times computers?

[CoastalMaineBird]

 could anyone explain why some VI do have the same CRC when built at different times computers?

A valid point.  If it was a timestamp in the build process, one would expect EVERY build of EVERY project to be different.

It seems like there has to be SOME setting that is affecting SOME build specs but not others.

Did you try the idea I posted earlier about re-creating the Build Specs?