We use an automatic method of embedding the ClearCase label selecting the product we are building into delivered objects. The label for C and C++ code is inserted via a preprocessor define in the BSD what style where a preamble of "@(#)" is prepended to the label. For other objects like Java jar files we put the label string into the manifest file. We use scripts to insert the label into RPM info records as well. Our applications display and log their version label on execution start up.
If you insert a label then you must check that what you inserted matches what you would insert on a rebuild or your identification can be come stale and invalid, much like one of my favorite computer bains the unrefreshed cache.
Version identification in the build process for C and C++ is done with the following make file fragments.
# Get version identification if we are in ClearCase SET_VERSION = $(TOP)/../inf_generic/cpp/bld/set_version REL_VERSION = $(shell PATH=$(PATH) $(SET_VERSION)) JREL_VERSION = $(shell PATH=$(PATH) $(SET_VERSION) -Java) CHECK_VERSION = $(TOP)/../inf_generic/cpp/bld/check_version
# Can not share derived object files with # version strings compiled into them. #.NO_WINK_IN: $(OBJ_DIR)/Version.$(OBJ_EXT) .NO_WINK_IN: Version.o Version.obj $(OBJDIR)/Version.$(OBJ_EXT): Version.cpp $(SET_E); $(MKDIR) $(OBJDIR); $(COMPILE_VER_OBJ) # Make sure we rebuild version object files that have a version # string compiled into them if the version string has changed. rm_version: @$(TEST) -f $(OBJDIR)/Version.$(OBJ_EXT) || exit 0; \ $(ECHO) Checking version object file $(OBJDIR)/Version.$(OBJ_EXT); \ PATH=$(PATH) $(CHECK_VERSION) $(CMWHAT) \ $(OBJDIR)/Version.$(OBJ_EXT) $(REL_VERSION); \ $(TEST) -f $(OBJDIR)/Version.$(OBJ_EXT) || \ PATH=$(PATH) "$(MAKE)"
Version identification in the build process for ANT Java build example
the following build.xml.
shell wrapper set_version
perl script set_version
shell wrapper check_version
perl script check_version
modified version of BSD what program
man page for BSD what program