Identifying files used in a CVI build of an exe

[Baldy_Bloke]

Hi

This is probably more a C type question, but since I am using CVI, I thought I'd ask the CVI community.

I have created several *.c files and gathered them together in a project along with Instrument Drivers, *.h files and UIR files. I have created an *.exe file and all is well.

Now I have to archive all these "source" files so that I can reproduce the "distributed" *.exe at a later date if it gets lost or damaged. I have to make an exact copy of the *.exe file in that it gives the same CRC code as the original *.exe. If this is not the case the two files are different and could behave differently.

How do I identify ALL the files that have been used for this particular build of the *.exe file? I somewhat assumed that the build.ini file would show this, but the build.ini also includes files from other projects within my workspace and is therefore somewhat unreliable, unless I have one project per workspace, then what is the point of the workspace?

There is also the question of the environment. Is there a cvi file that details exactly what configuration the environment was when the original *.exe was created?

What about if I upgrade my CVI package from say 7.0 to 8.0, will the system *.h files be the same and behave the same as the earlier version?

What about all those *.h files that are called from other *.h files, how are these identified?

The question of a source control package has been discussed, but this will only work if all the files have been identified and then we are back to the original question.

This scenario must be the same for all CVI programmers and so what do others do?

I have worked with LABView and found that when building a *.dll ALL vi's, even those from the system, are included. Is this the same for CVI and can the file be interrogated to find which files have been used?

Your answers are welcome and I'll pick the best to implement.

Many Thanks for your help.

[RobertoBozzolo]

This is a partial response to your questions...

Part of the informations you need are store in the .PRJ file, which holds compiler options and defines, run options, and external compiler support options.

Up to version 5.5 the PRJ file included also a full list of  #include files needed for your executable, but this information was lost starting from version 6 (or maybe moved elsewhere, I don't know where but really I never cared about it...).

I don't know what happens moving from one version to another, since I usally save only project files leaving the IDE choose system #include files by itself. I never had problems doing this: my applications needed only very few if none at all adaptations when upgraded to new releases of CVI, but I am really not concerned in versioning since my applications are highly customized (almost one per every customer ) so I can keep track of all changes and handle them one-by-one.

[Mert_A.]

Unfortunately, even if you could archive all aspects of your system state that went into the build of your .exe (which in itself is a very open ended problem), CVI does not necessarily generate an identical binary.  This issue came up before, and it turns out there are many factors causing this that cannot easily be fixed.

My question would be why you have to archive anything besides the .exe itself?  Why would you need to rebuild it, if all you want is an exact binary copy of the file?  Usually the point of saving a snapshot of a project's code base is to allow patching or other such changes to old, released versions.  If you're just worried about recovery if the distributed .exe gets lost or damaged, then backing it up to a redundant drive array and/or CDs sounds like a much easier way to go.

Mert A.
National Instruments