automatic build numbers

[df]

hmm anyone know an easy way to do this with gnu make?

currently i have a lil app i wrote (verbuild) which I call after I build my stuff to auto inc the build number in 'VERSION' file... and make exports the contents of VERSION via -D to the code on compilation...

seems an ugly way of doing it tho....

hows everyone else do it?

the code is ugly, but works fine....

if anyone is interested, to use it....

at top of your Makefile

Code: Select all

include VERSION

in your GCC line or flags etc

Code: Select all

EXTRAFLAGS=-DVERSION='"$(VERSION)"'
....
gcc $(EXTRAFLAGS)

and my build line looks like

Code: Select all

all : loader.exe verbuild.exe

loader.exe: $(OBJS)
   $(LD) $(LDFLAGS) $(OBJS) -o loader.exe

verbuild.exe:
   verbuild.exe

as i said, its pretty crap, but works for me, and I dont know any different...... heh...

anyone got better way of doing it? (no perl or python etc thanks, i have sed+awk tho... never learnt to use em)...

(compiled+tested uner vc6.0 and gcc)
oh, it also looks + updates 'version' file in CURRENT directory...


[attachment deleted by admin]

[Solar]

I consider this to be a thing of the version control system. After all, you want that build number to be the same for all developers building from identical source, no?

With CVS, you could add some checkin-script bumping a global build number upon each checkin.

Subversion tracks a global revision number anyways; all you have to do is add "$Revision$" to your code and enable keyword replacement.

[df]

checking code in and out 10 times has naught to do with build numbers for me. i know cvs/rcs systems track it. but they track it on individual files, not entire project build numbers.

[Pype.Clicker]

actually, i have a small tool that creates version.h out of a "version.id" file, and another tool that change the x.y.z numbers of the version when i do "ver --version", "ver --evolution" and "ver --release" respectively.

Other huge projects use the current $(HOST) and `date` to create the "build" identifier.

[Solar]

checking code in and out 10 times has naught to do with build numbers for me.

Well, as long as code doesn't change, it's the same build. And it changes only upon check-in, making it a new build. That's why I consider it a VCS problem.

i know cvs/rcs systems track it. but they track it on individual files, not entire project build numbers.

That's why I mentioned making a script run on every CVS check-in, bumping a global build number stored somewhere else.

As for Subversion, that VCS doesn't track individual file revision numbers at all. Every check-in bumps the global revision number of the repository. That makes SVN's $Revision$ exactly what you're looking for.

(I suggest reading up on Subversion at http://subversion.tigris.org. I consider it a vast improvement over CVS, especially on the admin side exactly because it does away with the per-file versioning. It also supports copying and moving files without losing the history; it takes some time to get used to the concept, and some re-thinking of how to branch, but then it's a charm.)

[df]

is subversion the same POS that requires you to run a HTTP server? i know some new rcs system pushes it all through http...

thats what I call BLOAT that I dont need on my workstation. (since all my stuff is local, one 1 single laptop...)

[Solar]

Close.

Subversion, in its "native" form, uses an Apache module to "outsource" all the networking and authorization stuff to a piece of code that's well proven, most likely already installed on a project's server, and already has it's port open in the firewall.

It also has the advantage of providing a HTTP based read-only access to the repository to anyone having a browser, and a generic read/write interface for anyone having a WebDAV compliant browser.

For the rest (like you), there's the alternative of running the "svnserve" standalone server.

[mr. xsism]

i thought about using build numbers, but why in the world does it matter?

btw, i would do what you are doing df, just make a lil app and call it each time you build.

[Solar]

It matters the moment you are no longer alone in your efforts, and bug reports are coming in, and you start wondering which version the reporter was using.

"Try again with the latest version and see if the bug is still there" is convenient for you, but not the other guy.