lunes, 28 de diciembre de 2015

hbmk2 y los VCS


Toda la vida he estado usando el fichero makefile, y concretamente, para Borland C, para contruir la aplicación en Harbour.

Desde hace relativamente un año, decidí que era demasiado complicado mantener dicho makefile, sobretodo cada vez que tenia que introducir alguna librería nueva en el sistema, averiguar ya de por si que librerías eran todo una odisea.

Así que me puse a mirar hbmk2 de Viktor Szakats. Una autentica maravilla!
Mirando la documentación, y me paro en estos 2.

-vcshead=<file>     genera un archivo de cabecera .ch con información del
                    repositorio local. Actualmente están soportados Git, SVN,
                    Mercurial, Bazaar, Fossil, CVS y Monotone. El archivo de
                    cabecera definirá la constante de preprocesador
                    _HBMK_VCS_TYPE_ con el nombre del VCS detectado, y
                    _HBMK_VCS_ID_ con el ID Único del repositorio local. Si
                    no se detecta un VCS, un número secuencial será
                    incrementado cada vez que se construya.


 -tshead=<file>      genera archivo de cabecera .ch con información de
                    fecha/hora. Cabecera generado definirá macros
                    _HBMK_BUILD_DATE_, _HBMK_BUILD_TIME_,
                      _HBMK_BUILD_TIMESTAMP_ con fecha/hora de creación de
                      archivo


Siempre, desde que uso un VCS, pasando desde CVS y SVN, teníamos la posiblidad de poner un define con una marca, donde el propio control de versiones lo cambiaba.

Con Git, esto no es posible directamente, porque el hash es sobre el cálculo del estado actual
del repositorio, hay que hacerlo a posterior.

Bueno, ¿ y todo esto para que sirve ? Muy simple, tenemos que identificar de alguna manera que la aplicación que está corriendo de que código fuente depende. Así, encontrar un bug, es tan simple de ir a esa versión tal y como estaba y mirar de arreglar y parchear en el código actual.

Hasta ahora tenía una forma muy simple, y es que siempre tener una marca, como;
#define df_Version  "27/10/2105 10:10 master"

Cada vez que generaba una versión nueva, tengo que acordarme de cambiarlo.
Esto me sirve para recorrer después fácilmente la historia e identificar el commit.

Ahora con hbmk2 puedo hacer que lo hago por mí, añadiendo el hash a la versión que corresponde, tan simple como añadir esto en nuestro fichero de compilación ;
-vcshead=./include/cv.ch
-tshead=./include/bd.ch



Después, en nuestro prg, añadimos ;

#include "cv.ch"
#include "bd.ch"

#define df_Version "id:" + _HBMK_VCS_ID_ + " date:" +_HBMK_BUILD_DATE_ + " time:"+ _HBMK_BUILD_TIME_  

La fecha/hora no es la del commit, es cuando lo estas generando actualmente.
 Entonces  la manera de proceder es simple;
  • Modifica / Crea / Borrar código
  • git commit
  • hbmk2 
Puede ser que queramos tener los ficheros .ch en el control de versiones, esto ocasiona que siempre te avisará que hay cambios.

Tan simple como aplicar nuestro ocultamiento al estilo Naruto ;-), usando http://xthefull.blogspot.com.es/2015/11/ignorar-fichero-del-repositorio-en-git.html

Ahora, cada vez que compilo, ya no tengo que preocuparme de cambiar nada, la aplicación ya me dirá cuál commit es la que se usó para generarlo;
 
id:de867af date:20151228 time:163110

Después tan facil como ver ;

λ git log --stat de867af
commit de867af8fbec6768118b019c3af60331f2faec01
Author: Rafa Carmona <rafa.thefull@gmail.com>
Date:   Mon Dec 28 16:29:29 2015 +0100

    Soporte completo para identificar version de Git a traves de Harbour

      * include/bd.ch y include/cv.ch son generados automáticamente por Harbour
        NO TOCAR

 include/bd.ch | 4 ++++
 include/cv.ch | 2 +-
 project.hbm    | 1 +
 server.prg    | 3 ++-
 4 files changed, 8 insertions(+), 2 deletions(-)