nsnb
19th October 2008 15:05 UTC

Automatically Update VER_BUILD when include file changed
Using the VERSION method exemplified in the various samples that come with NSIS is straightforward and easy in a single file .nsi script:

!ifndef VERSION
!define VER_MAJOR "3"
!define VER_MINOR "0"
!define VER_REVISION "1"
!define VER_BUILD "15"
!define VERSION ${VER_MAJOR}.${VER_MINOR}.${VER_REVISION}.${VER_BUILD}

However, when the product's .nsi script remains unchanged but one (or more) of the !include files in it change, I currently must edit the product's .nsi file manually, only to change VER_BUILD (or VER_REVISION). This is currently my poor man's solution to reflect the fact that a newly compiled setup.exe is different from the previous one.

My problem now is that I have numerous such main scripts and it is simply too tedious to manually update every one of them whenever a dependency !include file changes...

Is there a way or solution to automatically increment VER_BUILD or VER_REVISION whenever one of the !include files in the script changes?

demiller9
19th October 2008 17:40 UTC

This should get you thinking. Here's a snippet from one of my nsi scripts.

!execute "wscript.exe ..\BuildNum.vbs"
!include "BuildNum.nsh"
VIProductVersion  "${VERSION}.${BuildNum}"

and BuildNum.nsh looks like this:

!define BuildNum 8274.5

Our development team defines the Major and Minor version numbers and I append a 4 digit value for the date plus a serialized number for the installer build number.

Anders
19th October 2008 22:20 UTC

There are several ways to do this:

a)
use !execute or !system to generate some external nsh that you include

b)
use !searchparse (or !define /file)

c)
use a special include file that is both a valid nsis header and .h for C/C++ (See http://anders.nsis.pastebin.com/f575397bc for a ugly example)

nsnb
19th October 2008 22:40 UTC

Thanks demiller9 and Anders. I think that demiller9's suggestion along with Anders's option (a) is the only viable option, since the mechanism must be smart at least like make/nmake.

The reason is that I need a system that knows several things, not one:[list=1][*] Determine which !include files are dependencies.[*] Determine that one of the !include dependency files is newer (based on timestamp and perhaps content).[*] Automatically increment the build number.[*] Perhaps more (did I forget something?)[/list=1]
Funny, because I initially thought of the setup program as something outside of the make/nmake system.

But now it seems that good development methodology must involve make for compiling well structured NSIS scripts as well.