If the executables from the prior build existed, you could use the FileSystemObject (see vbld_FSO in the help index for details) to retrieve their last modification time and store them in temporary macros.
If the build box will not have the executables from a prior build (which it sounds like is the case), or if they will be re-created with each build anyway (i.e., you're building C# or VB.NET projects), then their timestamps won't be helpful. You would need to perform a diff on each source file of each project to determine if anything has changed since the last build.
Neither way is trivial to implement or maintain. You may want consider alternatives. For instance, when we build VBP, we have a major product version (i.e., 5.0, 5.1, etc.) that we keep in the ProductVersion of the main exe project and show on the About dialog. We use the auto-increment logic to increment the FileVersion of each project when built (i.e. 5.0.0.1 -> 5.0.0.2) so that each individual component version changes whenever that project's executable is built.
As far as build vs. rebuild in VBP, if a project is opened and built in the GUI and it completes building, building again won't do anything because all steps are marked completed. Rebuild will reset the build status of all steps and start the build over again. By default, the build status is not saved with the project file, so all steps will always be built from an automated build, since the build will occur in a new instance of VBP. The topic 'build -> Building Projects' in the help index goes into more detail on how it all works.
|