FWIW, here’s the a snippet from my version header file:
#define FK_VERSION_MAJOR 1 // Major version number
#define FK_VERSION_MINOR 2 // Minor version number
#define FK_VERSION_BUILD 1 // Build number
#define FK_VERSION_EDIT 663 // Edit number
#define FKVERSION
FK_VERSION_MAJOR,FK_VERSION_MINOR,FK_VERSION_BUILD,FK_VERSION_EDIT
Then a snippet from my .rc file:
//
// FKVERSION is defined in fkversion.h as a sequence of 4 digits: 1,2,3,4
// This is used as-is in FILEVERSION and PRODUCTVERSION.
// The macros below stringify the version for FileVersion and
ProductVersion.
//
#include “fkversion.h”
#define FK_VALUE2(Name,Value) VALUE #Name, #Value
#define FK_VALUE(Name,Value) FK_VALUE2(Name,Value)
#define FK_VALUE_STRING(Name) FK_VALUE(Name,FKVERSION)
VS_VERSION_INFO VERSIONINFO
FILEVERSION FKVERSION
PRODUCTVERSION FKVERSION
BEGIN
BLOCK “StringFileInfo”
BEGIN
BLOCK “040904b0”
BEGIN
// …
FK_VALUE_STRING(FileVersion)
FK_VALUE_STRING(ProductVersion)
END
END
BLOCK “VarFileInfo”
BEGIN
VALUE “Translation”, 0x409, 1200
END
END
I do similar nonsense with a timestamp string generated by TIMESTAMP in
the header file.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vodicka, Michal
Sent: Monday, March 29, 2004 1:57 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Getting version info?
From: Ken Cross[SMTP:xxxxx@comcast.net]
Reply To: Windows File Systems Devs Interest List
Sent: Monday, March 29, 2004 8:37 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Getting version info?
That’s a good idea – specify the build/version info as a part of
C_DEFINES,
right? (Since USER_C_FLAGS don’t get passed to the resource compiler.)
Yes, something like this:
!IF DEFINED(BUILD_NUMBER) && $(BUILD_NUMBER)
C_DEFINES=$(C_DEFINES) -DBUILD_NUMBER=$(BUILD_NUMBER)
!ENDIF
where BUILD_NUMBER is defined by build engine and passed to build by -nmake
parameter. I’m not sure about resource compiler because we generate whole
version info separatedly using m4 tool so it don’t need to be parametrised
more.
Yes, VCS/RCS/CVS/SCCS/whatever are good (I’ve used them on non-Windows
systems for years, and VSS on Windows), but I’m not aware of any that
produce version numbers like those needed in the .rc file. May be some
around, though…
The disadvantage is expanded keywords contain current file version number
which may not be what you need. If you have VSS, keywords are documented
somewhere. Also, using keywords for generating numbers usable in .rc file
would need some clever preprocessor tricks. I meant opposite case: ignore
version info and use numbers compiled in sources. For diagnostics it is
usually sufficient.
The best case is to have build engine integrated with VCS with automatic
labeling during build. Then, everything is reproducible and you can easily
get exact shapshot for every build, correct symbols etc. Build number is
everything you need. Invaluable when you have to solve problem with year old
binaries.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
