Thread: auto incremeting build number

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    519

    auto incremeting build number

    Hi,

    what is your preferend solution to include auto-incrementing build numbers into your builds (maybe with the help of some VS function, but I think it has none, so I'm not asking in the windows forum)?

    Thank you in advance!

  2. #2
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    Compilation date and time? They are implementation defined macros if my memory serves me right.

  3. #3
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    I thought about that. It would have the drawback that the same binary can have different build numbers.

    After one more coffee I think I know now that even a real build number is not precise enough for my needs, because pressing F7 twice would also give different numbers for the same binary.
    I think I'll have to create a tool which parses branch name and revno from bazaar and when creates a header file with that string defined inside

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Eh, doesn't bazaar have $Id$ replacement?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    I tried but I couldn't find anything about that. The closest thing seems to be something like

    Code:
    bzr version-info --custom \
         --template="#define VERSION_INFO \"Project 1.2.3 (r{revno})\"\n" \
         > version_info.h
    combined with the --check-clean flag

  6. #6
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by pheres View Post
    After one more coffee I think I know now that even a real build number is not precise enough for my needs, because pressing F7 twice would also give different numbers for the same binary.
    Just some disjointed thoughts...

    I use Perforce for SCM both at work and home and the changelist number is a good unique identifier for a particular revision of the source tree. The problem is that if you are storing multiple products in the depot then each of these products might have the same build number just because they happened to be built at the same CL. In practice that hasn't caused too many issues.

    I think it is beneficial to distinguish between dev builds and prod builds. Dev builds are ad-hoc and might not even possess a meaningful version number although you should have some way of identifying the exact revision ANY build was built from (as I said in Perforce the CL is a good way to do that). However dev builds are often built off trees which haven't been checked in yet so they might not have an assigned CL. In those circumstances it is sometimes useful for each developer to work on their own individual branch so that they feel free to check in before every built, but this increasing merging. Prod builds would automatically roll the build number when built.

    For an SCM environment which has no explicit support for global revision identifiers you can keep an explicit BuildDescriptor file and update this at every checkin. The tradeoff is that the build descriptor has to be explicitly locked if you want to maintain a monotonic ordering of build numbers.

    In VS, you could add a custom pre-build step which increments the version number in a header file or resource definition file. For UNIX environments you could use a shell script and integrate it as part of the build process.

    Another piece of advice -- when you access your version number/build number internally from your code, do it through a function instead of accessing the build number macro directly. This prevents tons of stuff from rebuilding just because the build number header got changed. It also makes it possible to easily hot-patch the version number in the binary which can be useful in a number of circumstances.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by brewbuck View Post
    Just some disjointed thoughts...

    I use Perforce for SCM both at work and home and the changelist number is a good unique identifier for a particular revision of the source tree. The problem is that if you are storing multiple products in the depot then each of these products might have the same build number just because they happened to be built at the same CL. In practice that hasn't caused too many issues.
    In bazaar the depot is called repository and can also contain lot of branches each belonging to one or another product. the good thing is, that the revision number is branch-, not repo specific. committing to one branch doesn't affect the revno of other branches. so this is solved.

    I think it is beneficial to distinguish between dev builds and prod builds. Dev builds are ad-hoc and might not even possess a meaningful version number although you should have some way of identifying the exact revision ANY build was built from (as I said in Perforce the CL is a good way to do that). However dev builds are often built off trees which haven't been checked in yet so they might not have an assigned CL. In those circumstances it is sometimes useful for each developer to work on their own individual branch so that they feel free to check in before every built, but this increasing merging. Prod builds would automatically roll the build number when built.
    We're using a very decentral approach, where every developer owns oen or more branches. I maintain a common branch, in which I merge all other branches on feature updates or bug fixes. after stabelizing the common branch is merged into a release branch. the revisions inside the release branch are then tagged as version and shipped. so dev andf prod builds are always very apart from each other.

    In VS, you could add a custom pre-build step which increments the version number in a header file or resource definition file. For UNIX environments you could use a shell script and integrate it as part of the build process.
    Yes, that's exactly what I plan to do.

    Another piece of advice -- when you access your version number/build number internally from your code, do it through a function instead of accessing the build number macro directly. This prevents tons of stuff from rebuilding just because the build number header got changed. It also makes it possible to easily hot-patch the version number in the binary which can be useful in a number of circumstances.
    Thanks, I'll definitely follow this one.
    Last edited by pheres; 11-10-2008 at 05:21 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. memory issue
    By t014y in forum C Programming
    Replies: 2
    Last Post: 02-21-2009, 12:37 AM
  2. Need help with this compiler error
    By Evangeline in forum C Programming
    Replies: 7
    Last Post: 04-05-2008, 09:27 AM
  3. Automatic build number on about page
    By ratte in forum C++ Programming
    Replies: 9
    Last Post: 01-04-2008, 05:23 AM
  4. adding a number to a number
    By bigmac(rexdale) in forum C Programming
    Replies: 11
    Last Post: 10-24-2007, 12:56 PM
  5. auto build date
    By GreyMattr in forum C Programming
    Replies: 2
    Last Post: 06-25-2002, 02:10 PM