RE: Automatically increment build number

[Weber, Mathias-Henry 1254 PPW-P1]

> -----Original Message-----
> From: Matthew Riechers [mailto:address@hidden
> Sent: Tuesday, 8. May 2001 14:01
> To: Weber, Mathias-Henry 1254 PPW-P1
> Subject: Re: Automatically increment build number
> 
> 
> 
> "Weber, Mathias-Henry 1254 PPW-P1" wrote:
> > 
> > I want my project to output the actual build number. My 
> idea is to have a C
> > file containing the build number and automatically 
> increment this build
> > number each time anybody issues a "commit".
> > 
> > In principle this would mean the following steps:
> > 
> >         committing "Modified.cpp" starts
> >                 checkout "BuildNo.cpp"
> >                 increment build number within file "BuildNo.cpp"
> >                 committing "BuildNo.cpp" starts
> >                 committing "BuildNo.cpp" ends (hopefully)
> >         committing "Modified.cpp" ends
> > 
> > Now the problem is twofold:
> > 
> > 1. The commit process is recursive which will probably 
> result in a deadlock
> > situation
> > 2. The checkout of "BuildNo.cpp" happens on the server. 
> What is the best way
> > to accomplish/enforce an update on all clients?
> > 
> > [ ... ]
> 
> A build usually implies compiling, not editing. Why do you 
> want to track the number of commits? If you are actually
> trying to count the number of builds, increment the value of 
> BuildNo.cpp when you do the *build*. If you are building
> with some sort of Makefile or script system, it should be 
> trivial to add a 'increment_build.sh; cvs commit BuildNo.cpp'
> to it.
> 

Of course you are right that I'd rather count the number of build runs. But
since we actually do not have a central build server this is even more
meaningless than updating the counter with every commit. 

Another problem with coupling the incrementing of the counter to the build
process would mean that this would have to be performed on every client
host. The clients run Windows NT which is not my favourite choice for
running script jobs. Furthermore the clients are rather differently equipped
in terms of software the only common tool for script programming would be a
DOS batch job. Do you understand that I am still interested in a different
solution?

I do not realy want to count the number of build runs but rather have at
least some meaningful indication about the included features of a certain
executable. The build time of an executable could be quite recent but if the
developer did not update recently it does not indicate that a feature is
available or not. 

Any further ideas?

Mathias