[PATCH] Add revision information to the VSMS
# HG changeset patch # User Dan Smith <danms@us.ibm.com> # Date 1207934505 25200 # Node ID 52e2f501b44994af849df3a8e354bbe6097cd9d6 # Parent 17cf33b5cf9ac533d51f73037a6f08499dc0a67b Add revision information to the VSMS This is done at build time, if possible. If not, the changeset/revision at the last automake run will be used. This should make it work for the tarball/release case as well as the RPM build. The way this works, if you build, then apply a patch or pull a new changeset, the exposed revision/version information will be stale unless you do a clean. Since this is really just for the purposes of test-tracking, I think this is a reasonable restriction that can be minded by the people doing testing. The changeset hash and revision number are exposed in aptly-named properties of the VSMS for each platform. If anyone has a better place for these to show up, or a better format, please bring it up. Signed-off-by: Dan Smith <danms@us.ibm.com> diff -r 17cf33b5cf9a -r 52e2f501b449 Makefile.am --- a/Makefile.am Fri Apr 11 09:53:15 2008 -0700 +++ b/Makefile.am Fri Apr 11 10:21:45 2008 -0700 @@ -98,7 +98,8 @@ pkgdata_SCRIPTS = provider-register.sh EXTRA_DIST = schema $(pkgdata_DATA) $(pkgdata_SCRIPTS) \ libvirt-cim.spec.in libvirt-cim.spec \ - doc/CodingStyle doc/SubmittingPatches + doc/CodingStyle doc/SubmittingPatches \ + .changeset .revision preinstall: sh -x base_schema/install_base_schema.sh `pwd`/base_schema diff -r 17cf33b5cf9a -r 52e2f501b449 acinclude.m4 --- a/acinclude.m4 Fri Apr 11 09:53:15 2008 -0700 +++ b/acinclude.m4 Fri Apr 11 10:21:45 2008 -0700 @@ -313,4 +313,23 @@ AC_DEFUN([DEFINE_DISK_CONFIG], [ AC_DEFINE_UNQUOTED([DISK_POOL_CONFIG], "$1", [Disk pool config filepath.]) ] -) \ No newline at end of file +) + +AC_DEFUN([SET_CSET], + [ + if test -d .hg && test -x $(which hg); then + cs='-DLIBVIRT_CIM_CS=\"`hg id -i`\"' + rv='-DLIBVIRT_CIM_RV=\"`hg id -n`\"' + elif test -f .changeset; then + cset=$(cat .changeset) + revn=$(cat .revision) + cs="-DLIBVIRT_CIM_CS=\\\"$cset\\\"" + rv="-DLIBVIRT_CIM_RV=\\\"$revn\\\"" + else + cs='-DLIBVIRT_CIM_CS=\"Unknown\"' + rv='-DLIBVIRT_CIM_RV=\"0\"' + fi + + CFLAGS="$CFLAGS $cs $rv" + ] +) diff -r 17cf33b5cf9a -r 52e2f501b449 autoconfiscate.sh --- a/autoconfiscate.sh Fri Apr 11 09:53:15 2008 -0700 +++ b/autoconfiscate.sh Fri Apr 11 10:21:45 2008 -0700 @@ -17,4 +17,12 @@ echo "Running autoconf ..." && echo "Running autoconf ..." && autoconf --force && +if test -x $(which hg); then + hg id -i > .changeset + hg id -n > .revision +else + echo "Unknown" > .changeset + echo "0" > .revision +fi + echo "You may now run ./configure" diff -r 17cf33b5cf9a -r 52e2f501b449 configure.ac --- a/configure.ac Fri Apr 11 09:53:15 2008 -0700 +++ b/configure.ac Fri Apr 11 10:21:45 2008 -0700 @@ -143,6 +143,7 @@ AC_SUBST(CFLAGS_STRICT) AC_SUBST(CFLAGS_STRICT) CFLAGS="$CFLAGS $CC_WARNINGS" +SET_CSET # Display configuration options echo "----------------------------------------------------------" diff -r 17cf33b5cf9a -r 52e2f501b449 src/Virt_VirtualSystemManagementService.c --- a/src/Virt_VirtualSystemManagementService.c Fri Apr 11 09:53:15 2008 -0700 +++ b/src/Virt_VirtualSystemManagementService.c Fri Apr 11 10:21:45 2008 -0700 @@ -1244,6 +1244,12 @@ CMPIStatus get_vsms(const CMPIObjectPath CMSetProperty(inst, "SystemCreationClassName", (CMPIValue *)ccname, CMPI_chars); + CMSetProperty(inst, "Changeset", + (CMPIValue *)LIBVIRT_CIM_CS, CMPI_chars); + + CMSetProperty(inst, "Revision", + (CMPIValue *)LIBVIRT_CIM_RV, CMPI_chars); + if (is_get_inst) { s = cu_validate_ref(broker, reference, inst); if (s.rc != CMPI_RC_OK)
Dan Smith wrote:
# HG changeset patch # User Dan Smith <danms@us.ibm.com> # Date 1207934505 25200 # Node ID 52e2f501b44994af849df3a8e354bbe6097cd9d6 # Parent 17cf33b5cf9ac533d51f73037a6f08499dc0a67b Add revision information to the VSMS
This is done at build time, if possible. If not, the changeset/revision at the last automake run will be used. This should make it work for the tarball/release case as well as the RPM build.
The way this works, if you build, then apply a patch or pull a new changeset, the exposed revision/version information will be stale unless you do a clean. Since this is really just for the purposes of test-tracking, I think this is a reasonable restriction that can be minded by the people doing testing.
The changeset hash and revision number are exposed in aptly-named properties of the VSMS for each platform. If anyone has a better place for these to show up, or a better format, please bring it up.
You'll also need to modify the mof file to add the new attributes, right? I think this a neat approach. I'm not sure whether VSMS is the correct place.. I initially thought this would be good to add to the profile, but I don't know if we want to advertise this info there. The SoftwareIdentity class has attributes for this kind of information, but it definitely doesn't fit in the scope of the VSP and SVP. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
KR> You'll also need to modify the mof file to add the new attributes, KR> right? Yeah, we should. KR> I think this a neat approach. I'm not sure whether VSMS is the KR> correct place.. I initially thought this would be good to add to KR> the profile, but I don't know if we want to advertise this info KR> there. I think it's probably the best of the options, without dragging another profile and/or provider into the mix. So, was that a +1 or at least something that rounds up to 1? :) -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
KR> You'll also need to modify the mof file to add the new attributes, KR> right?
Yeah, we should.
KR> I think this a neat approach. I'm not sure whether VSMS is the KR> correct place.. I initially thought this would be good to add to KR> the profile, but I don't know if we want to advertise this info KR> there.
I think it's probably the best of the options, without dragging another profile and/or provider into the mix.
So, was that a +1 or at least something that rounds up to 1? :)
I'll chip in to get it up to one providing the mof change gets made as well. -- -Jay
participants (3)
-
Dan Smith -
Jay Gagnon -
Kaitlin Rupert