Integrating subversion build number

Follow

Ben Stuyts

• June 18, 2010 13:35

Hi,

We're using svn for our revision control, and I'd like to use the svn build# for building a version string. With conventional makefiles I'd use something like

CFLAGS+=-DSVN_VERSION="`svnversion`"

but I don't see a way of doing that with CrossWorks. I know I could create an svnversion.h file using the pre-compile command option, but that would run before compiling each and every file.

Any ideas?

Thanks,

Ben

0

• 

  Jon Elliott

  • June 18, 2010 16:31

  I've just added ...get the current Subversion version number to the "How Do I..." forum, I hope it helps.

  Regards,

  Jon

  0

  Comment actions Permalink
• 

  Ben Stuyts

  • June 18, 2010 17:26

  Thanks Jon, I'll go try that. Much appreciated!

   

  Kind regards,

  Ben

  0

  Comment actions Permalink
• 

  Darcy Williams

  • June 18, 2010 23:31

  We have something similar to the "how to" Jon posted above, and maybe Jon's method could easily do this as well...

  We have a "template" file called template_svn_product_info.h containing:

  #define    PRODUCT_TREE_SVN_REVISION        $WCREV$
  #define    PRODUCT_TREE_IS_MODIFIED        $WCMODS?1:0$
  #define    PRODUCT_TREE_IS_MIXED            $WCMIXED?1:0$
  
  const char*        AUTO_VERSION_SVN_DATE        = "$WCDATE$";
  const char*        AUTO_VERSION_BUILD_TIME        = "$WCNOW$";
  
  #if    (PRODUCT_TREE_IS_MODIFIED || PRODUCT_TREE_IS_MIXED)
      #ifdef CONF_Formal_Release
          #error "Source trees contain local modifications"
          #error "Cannot compile release version in this state"
          #error "*** SVN Commit AND Update Required ***"
          #error
      #endif //CONF_Formal_Release
      #ifdef CONF_Dev_Release
          #warning "WARNING: Local modifications found, SVN Commit and SVN Update required"
      #endif //CONF_Dev_Release
  #endif
  #endif

   

  That templ.....h file is used by a batch file by doing something like this... which calls SubWCRev which comes with Tortoise SVN I think...

  SubWCRev %1 .\templ_svn_product_info.h %1\source\svn_product_info.h

  and now looks like this...  (except named svn_product_info.h instead of templ*.h

  #define    PRODUCT_TREE_SVN_REVISION        3158
  #define    PRODUCT_TREE_IS_MODIFIED        1
  #define    PRODUCT_TREE_IS_MIXED            1
  
  const char*        AUTO_VERSION_SVN_DATE        = "2010/06/18 13:55:41";
  const char*        AUTO_VERSION_BUILD_TIME        = "2010/06/18 15:26:40";

   

  We have just a single .c file that includes the header "svn_product_info.h".  That source file is set to build every time (in project properties), and as a prebuild command calls the batch file that has that batch file excerpt above.

   

  The .c file has a function something along the lines of this...

  void DeviceInfo_getVersionNumbers( firmware_version_t *version_numbers )
  {
      version_numbers->major = VERSION_MAJOR;
      version_numbers->minor = VERSION_MINOR;
      version_numbers->build = VERSION_BUILD;
      version_numbers->firmware_type = fw_type;
      version_numbers->svn.revision = PRODUCT_TREE_SVN_REVISION;
  }

  which also pulls in a file called version.h containing the product major/minor/build definitions (which we manually update per formal release)

  One of the main reasons of going through this process is to detect mixed and modified trees.  For example, the svn number alone doesn't help you rebuild a binary if you had files that were modified (and not checked in) at the time you built the code.  So when you get that svn revision from subversion some time in the future you wouldn't have those changes.

  That's why we have PRODUCT_TREE_IS_MODIFIED and PRODUCT_TREE_IS_MIXED.  We also have three types of build; debug, dev release, formal release.  Debug is for debug, formal release is something we release for testing/trials etc and dev release is for trying out ideas or just seeing how it works.  Formal release throws errors if the svn revisions aren't identical or if we have local modifications that haven't been checked in.  Dev release warns us that this is the case, but we don't care because we're just trying things out before we release.  Debug we don't care at all...

  Just another idea maybe someone can use...

  0

  Comment actions Permalink
• 

  Ben Stuyts

  • June 19, 2010 21:26

  Looks good, Darcy, many thanks for sharing.

  Kind regards,

  Ben

  0

  Comment actions Permalink

Please sign in to leave a comment.