Ver la versión completa : fecha y hora de compilacion automatica en el binario?
hola,
he visto que en algunos programas al ejecutarlos pone la version, y la fecha y hora de compilacion. no se si lo hacen a mano, pero me suena que es una variable o algo. Estoy hablando de un programita en C/C++, con gcc, y el kdevelop usa autoconf, automake, y auto-todo jeje.
Trabajo con kdevelop por si lo tengo que cambiar en kdevelop o en otro sitio.
Tambien decir que no consigo que me cambie el #define VERSION 0.1 que aparece en el config.h por mucho que lo cambio en todos los sitios que aparece en kdevelop. :(
Aiken
La forma más rápida que se me ocurre: gcc -DCOMPDATE=`date` ... y luego usas COMPDATE en tus fuentes
He googleado un poco y, al menos en gcc, es tan fácil como usar __DATE__ y __TIME__
printf("Compiled %s %s\n",__DATE__, __TIME__);
No hay que configurar nada en kdevelop. Eso sí, supongo que la hora será distinta en cada fichero objeto, o al menos en cada ejecutable/librería que compiles...
He googleado un poco y, al menos en gcc, es tan fácil como usar __DATE__ y __TIME__
Esto vale para cualquier compilador de C/C++, son variables del preprocesador, y se reemplazan por la fecha y hora actual. Asi que lo suyo es tener algo como
#define VERSION "Version 0.3.2 " __DATE__ " " __TIME__
**** que cojonudo lo del date y time. :brindis:
Y sabeis donde se cambia lo del VERSION en kdevelop? porque lo he cambiado en varios sitios que lo he encontrado pero sigue poniendome 0.1 :(
PD. Vale, vale, que me defino yo el version y a correr, pero era por si alguien sabia usar eso en el kdevelop, creo
que tiene algo quever con el configure porque hay un #define VERSION en el config.h generado automaticamente, y supongo que lo saca del proyecto de kdevelop pero no soy capaz de encontrarlo, lo he visto en dos sitios lo he cambiado y he hecho un rebuild de todo y sigue poniendo 0.1 :(
PD Por cierto gracias por lo de date y time :brindis:
Aiken
Eso de la versión me pasó a mi también
Edita el archivo configure.in, busca AM_INIT_AUTOMAKE, tiene que estar al principio, ahí pone el nombre del programa y la versión, cambia el 0.1 por la versión que quieras ponerle.
Eso de la versión me pasó a mi también
Edita el archivo configure.in, busca AM_INIT_AUTOMAKE, tiene que estar al principio, ahí pone el nombre del programa y la versión, cambia el 0.1 por la versión que quieras ponerle.
la pregunta: el configure.in no se regenera solo cada vez a partir del proyecto? no sea que lo cambie ahi y vuelva a regenerarse. la verdad no entiendo para que esta en la configuracion del proyecto si no se traspasa ahi. :(
Voy a probar a editarlo a mano el configure.in a ver que pasa.
Aiken
Que yo sepa el configure.in sólo lo toca kdevelop cuando creas el proyecto, y en el caso de que lo regenere, al menos esa línea la deja intacta. Lo digo porque yo lo he modificado y a mi no me ha cambiado nada automáticamente.
Que yo sepa el configure.in sólo lo toca kdevelop cuando creas el proyecto, y en el caso de que lo regenere, al menos esa línea la deja intacta. Lo digo porque yo lo he modificado y a mi no me ha cambiado nada automáticamente.
lo estoy mirando, y si que lo toca, y lo que es peor PASA BIEN LA NUEVA VERSION!
El problema es:
kdevelop te crea 2 "targets":
- debug
- optimized
que simplemente son que si eliges uno u otro compila con opciones de compilacion diferentes y deja los resultados en las carpetas debug u optimized.
El problema: existen 3 configure.h!! uno en cada carpeta de debug y optimized (para que ****) y otro donde estan los fuentes en src.
Pues resulta que al actualizar el proyecto, se actualiza el configure.h que esta en la carpeta del "target" activo :(
y cuando haces un #include "config.h" lo coge del "src" que no esta actualizado.
Aiken
< - >
PD. Pensandolo bien, parece logico que haya varios config.h uno para cada "target" pues tendra opciones difrentes no solo de compilacion sino de otras cosas.
Ahora el tema es. Desde el codigo que pongo #include "config.h"? #include "debug/src/config.h"?
me parece cutre esta ultima opcion porque habria que ir cambiando el include manualmente depende de que target quieras compilar :(
Aiken
Es decir, que sí modifica el configure.in, pero el que modifica es el del target activo, ¿no? Claro, por eso no me lo modificaba a mí, porque yo estaba mirando el del src cuando tenía activo el debug.
Eso es un bug, ¿no?
Yo he encontrado otro bug que me está fastidiando bastante. Al hacer el ./configure me mete en un Makefile la línea -I/usr/include/sigc++-2.0 en un punto del Makefile donde no debe, y claro al compilar da error. Tengo que modificar el Makefile a mano y borrar esa línea
Es decir, que sí modifica el configure.in, pero el que modifica es el del target activo, ¿no? Claro, por eso no me lo modificaba a mí, porque yo estaba mirando el del src cuando tenía activo el debug.
Eso es un bug, ¿no?
Pues no estoy seguro que sea un bug, lo mismo lo estamos haciendo mal. Piensa la idea esa de que cada target podria tener un config diferente con defines diferentes.
Lo que no se es porque crea 3 config.h uno en cada carpeta. O lo que es peor tiene logica que haya 3 por lo de configuraciones diferentes, pero como se refiere a cada uno sin tener que fisicamente escribir la ruta completa? :(
Yo he encontrado otro bug que me está fastidiando bastante. Al hacer el ./configure me mete en un Makefile la línea -I/usr/include/sigc++-2.0 en un punto del Makefile donde no debe, y claro al compilar da error. Tengo que modificar el Makefile a mano y borrar esa línea
no sera que tienes alguna opcion puesta en las opciones del proyecto, que necesita esa libreria, y el error que te esta dando es que no tienes esa libreria instalada?
a mi me pasaba lo mismo con las libtool, que creo que son algo para depurar codigo, y el te las mete por defecto y si no tienes instaladas esas liberias te peta.
yo lo que hice es instalar las libtool y a correr, porque no encontre en que parte del proyecto estaban activada esa opcion ... curiosamente hoy mirando esto otro me ha parecido ver una referencia a las libtool, pero ya no me he atrevido a tocarlo.
Si no quieres comerte el coco buscandolo, comprueba si tienes instalada esa lib y sino instalala y a correr ;)
Aiken
Claro que la tengo instalada, si el error que me da es "Makefile: error: falta un separador" y si hago click en el error me lleva a una línea del makefile que es ese -I/usr/include/sigc++-2.0 que está en un sitio que no debe, lo borro y ya compila perfectamente.
En concreto debería estar en la línea de INCLUDES, y efectivamente, está ahí pero además se cuela en otro sitio que no debe, y no sé porqué.
por curiosidad estoy buscando en mi proyecto a ver si aparece en algun lado esa liberia.
No creo que aparezca, la he añadido yo, es una librería de señales, tipo los slots y señales de la librería Qt. Se suele usar para librerías de interfaces de usuario. Y yo estoy haciendo una :D
Por ejemplo conectas la señal mouseclick de una instancia de un botón, a una función que actúe cuando esa señal (evento) ocurra.
No creo que aparezca, la he añadido yo, es una librería de señales, tipo los slots y señales de la librería Qt. Se suele usar para librerías de interfaces de usuario. Y yo estoy haciendo una :D
Lo cual nos lleva a la segunda paradoja de Matrix: cuando añades una libreria ... yo lo unico que he hecho ha sido añadir mis includes (en mi caso de la SDL_image) y en las opciones del proyecto añadir en una casilla un "-lSDL_image".
El tema es que ejecutando el configure a mano, no me va, porque me he dado cuenta que lo que hace el capullo del kdevelop (lo mismo es lo normal) es: primero pone el "-lSDL_image" como variable de entorno (creo que como LDFLAGS en el entorno) y luego ejecuta el configure y asi si funciona.
Pero es poco limpio eso de meterlo como variable de entorno para que lo coja en configure no? o es asi como se hace habitualmente? entiendo que no porque una persona que este ejecutando el configure desde linea de comandos tenga que acordarse de hacer un setenv a mano del "-lSDL_image" me parece raro.
Como haces tu para meter una libreria nueva?
Aiken
No se para que usais kdevelop, quiero decir, si es por algo en concreto que os ofrece, pero a mi ese IDE me da asquito, yo me pase al codeblocks y me olvide de esos pequeños bugs tan chorra que teneis
Lo cual nos lleva a la segunda paradoja de Matrix: cuando añades una libreria ... yo lo unico que he hecho ha sido añadir mis includes (en mi caso de la SDL_image) y en las opciones del proyecto añadir en una casilla un "-lSDL_image".
El tema es que ejecutando el configure a mano, no me va, porque me he dado cuenta que lo que hace el capullo del kdevelop (lo mismo es lo normal) es: primero pone el "-lSDL_image" como variable de entorno (creo que como LDFLAGS en el entorno) y luego ejecuta el configure y asi si funciona.
Pero es poco limpio eso de meterlo como variable de entorno para que lo coja en configure no? o es asi como se hace habitualmente? entiendo que no porque una persona que este ejecutando el configure desde linea de comandos tenga que acordarse de hacer un setenv a mano del "-lSDL_image" me parece raro.
Como haces tu para meter una libreria nueva?
Aiken
El problema de añadir una librería nueva de forma que lo coja el configure es que es muy difícil: hay que aprender la sintaxis de autoconf y hacer un código para incluirlo en el archivo aclocal.m4 (si lo lees verás lo complicado que es) Yo conseguí incluir SDL_image y OpenGL googleando, siento no poder decirte cómo lo hice porque no me acuerdo, hace ya bastante tiempo.
Ahora lo hago como lo haces tú, en el gestor de automake en el objetivo añado las librerías que necesito. Ya me preocuparé de pasarlo a autotools cuando termine el proyecto.
< - >
No se para que usais kdevelop, quiero decir, si es por algo en concreto que os ofrece, pero a mi ese IDE me da asquito, yo me pase al codeblocks y me olvide de esos pequeños bugs tan chorra que teneis
Uso KDevelop porque es mejor que Kate
No se para que usais kdevelop, quiero decir, si es por algo en concreto que os ofrece, pero a mi ese IDE me da asquito, yo me pase al codeblocks y me olvide de esos pequeños bugs tan chorra que teneis
pues por nada especial. yo siempre habia tirado de makefiles a mano, e incluso editaba con el VI jeje. Pero me instale Ubuntu y me ubuntualize y me volvi vago y dije voy a usar un IDE y puse buscar en el instalador de paquetes y salio el kdevelop y tampoco busque mas, porque para lo que necesito .... y pense que otros entornos tipo codeblocs iban a ser demasiado gigantes para las cuatro cosas que voy a usar yo. :)
Aiken
< - >
Ahora lo hago como lo haces tú, en el gestor de automake en el objetivo añado las librerías que necesito. Ya me preocuparé de pasarlo a autotools cuando termine el proyecto.
< - >
ya si a mi tambien me da un poco igual, pero mi profesor del PFC esta empeñado en que quiere compilar desde la linea de comandos poniendo "./configure ; make" y que no quiere escribir nada mas :(
y como tu dices, como me parece un poco capricho pues lo he ido dejando, pero algun dia tendre que "arreglarselo" para que quede asi y se quede contento ... o se aburre antes y deja de pedirme esa chorrada y nos centramos en lo importante del PFC :D
Aiken
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.