jci: me perdi con tu sugerencia que paso? naa que al libro de gnome le falta algo asi como un uso rapido de autoconf y demases para programacion en gnome alguien tiene que hacerlo :-) halley dijo usar anjuta o glade, pero la idea es no depender de eso :-) en too caso, si supiera, me mando un capitulo jejejejej http://www.gtk.org/faq/#AEN424 grax de todas formas, le falta un poco, pero esta bien mira el configure.in de un proyecto chico jejeje en eso estoy veamos si sale algo interesante a saber en desarrollo normalmente se utiliza un script llamado autogen.sh que se encarga de ejecutar aclocal, autoheader, autoconf y automake yeps, si asi lo he visto cuando trabajo con anjuta ademas de eso, cuando se genera el script configure, lo ejecuta ese script, autogen.sh puede ser cualquiera yeps cuando bajo algunas cuestiones del cvs viene ese juguete :-) para gnome2 existe uno que normalmente se copia de proyecto en proyecto pero cada uno lo modifica a su antojo cuando bajas un tar.gz el autogen.sh no viene sino que el configure viene listo anatomia de una fuente.tar.gz: esta compuesto por el script configure y un conjunto de archivo terminados en .in Makefile.in principalmente yeps a partir del cual se generaran los correspondientes Makefiles eso lo vi en el linux programming unleashed eso scripts nunca los toca el desarrollador y se generan despues de ejecutar "make distcheck" antatomia de un fuente de CVS: el fuerte se compone por los archivos: autogen.sh, configure.in y Makefile.am los 2 primeros existen en el raiz del proyecto que es un overlap Makefile.am existe uno en cada directorio que se utiliza en el proyecto el Makefile.am es bien pequeño, a partir del cual se genera el Makefile.in y posteriormente el Makefile ese proceso se hace con automake (de ahi la extension .am) que mas podria decir? analicemos el configure de un proyecto quiero decir, el configure.in hmmm algunas de las macros las entiendo solo que no me he puesto a cachurear las macros que son exclusivas de gnome son muy pocas las que corresponden a GNOME por ejemplo: estoy viendo el de gturing --> Dr_Neo (~Power_of_@irc.cl-339408.terra.cl) ha ingresado en #gnome y tambien el de gnome-network <-- Dr_Neo (~Power_of_@irc.cl-339408.terra.cl) ha salido de #gnome AC_PREREQ(2.52) eso indica, que se necesita la version 2.52 o superior de autoconf esto es, puedes tener distintas versiones de autoconf instaladas pero en tu proyecto podrias utilizar macros mas avanzadas (o reparadas) y asi, autoconf sabra cual llamar AC_INIT([gturing],[0.1.1],[gpoo@ubiobio.cl]) eso indica el nombre del paquete, la version y, opcionalmente, el autor a partir de esto se pueden añadir una serie de #define jejeej por ejemplo, esa linea quedara asi en el config.h #define PACKAGE "gturing" #define VERSION "0.1.1" entonces, en tu programa fuente colocas: #ifdef HAVE_CONFIG_H # include #endif y ya tienes esos #define del configure.in una ves vi un configure que decia cheking for a free radiation enviroment.....ok esas dos tipicamente se usan para registrar el nombre del programa por ejemplo, en el programa principal: :-) program = gnome_program_init (PACKAGE, VERSION, LIBGNOMEUI_MODULE, argc, argv, GNOME_PARAM_POPT_TABLE, gturing_options, GNOME_PARAM_APP_DATADIR, DATADIR, GNOME_PARAM_NONE); si te das cuenta, los 2 primeros parametros son PACKAGE y VERSION halley: se pueden añadir todos los chequeos que quieras :-) * invierno cerrando las ventanas, que entran los zancudos <-- jrami ha salido (Quit: [BX] Gary Coleman uses BitchX. Whatchoo talkin bout foo?) onda cheking for a free kde enviroment halley: si bueno luego tenemos: AM_INIT_AUTOMAKE(AC_PACKAGE_NAME,[0.1.1]) similar al AC_INIT notar las 2 primeras letras de las macros AC_ ==> autoconf y AM_ ==> automake es decir, esta inicializa automake AC_PACKAGE_NAME es una variable, que en este definimos en AC_INIT el primer parametro se supone que el segundo pudo ser AC_VERSION pero autoconf y automake no estan libres de errores y es un detalle menor AM_CONFIG_HEADER(config.h) es el archivo de configuracion donde quedan los define eso mas o menos es estándar jejeje lo que hay que tener en claro, es entre versión y versión las macros cambian pero una consulta german por ejemplo, aceptan mas o menos parámetros jci: dime la idea es que las macros de autoconf para gnome esten documentadas...como las de autoconf ah retiro la pregunta entonces :-( eso mismo que dijiste que entre version y version he visto que algunas macros no eran las mismas no es que no sean las mismas o sea, son las mismas, solo que cambian la cantidad de parametros y esas cosas por ejemplo, AC_DEFINE_UNQUOTED ahora pide mas argumentos pero sigue haciendo lo mismo cuando se ejecuta, envia un warning y te dice como solucionarlo no sep, quizas es carril, pero he visto que muchas de las macros de autoconf puras son exactamente las mismas para versiones antiguas jci: depende ah :-) como te digo, las macros de GNOME son pocas de hecho, hasta ahora no he mencionado ninguna macro de GNOME solamente de AC OT a cuanto esta el euro con relacion al dolar ? y AM 1 a 1 luego tenemos: AM_MAINTAINER_MODE modo mantención alguna vez lo leí pingu: creo que 3 euros es un dolar básicamente añade flags -Werror cuando se hace make distcheck creo :\ tella.cl :-) (ballo sin agua) jci: te cambio unos dolares por euros la relación es 1 a 1 okis :-) no cacho a cuanto estaba el cambio, toy intoxicated with caffeine :-) un detalle, antes de continuar como son macros M4 hay que ser muy cuidadoso con los espacios y tabuladores estos ultimos hay que evitarlos asi: AC_PROG_INTLTOOL$ es distinto a los tabuladores o los espacios? AC_PROG_INTLTOOL $ el $ es el fin de línea que obviamente no va pero ese espacio es interpretado y fallara en el segundo caso los tabuladores hay que evitar bueno, esa macro indica que queremos usar intltool intltool es la que permite trabajar con internacionalizacion ajap intltool son un conjunto de scripts en Perl que facilitan la vida se usa en conjunto con: AM_GLIB_GNU_GETTEXT es decir, trabajermos con gettext gettext tiene una macro reducida llama _() si alguna vez la han visto _("My string") yeps, la explicaste en la charla de curico gettext permite extraer esos textos y dejarlos en un archivo aparte pero no recuerdo que funcion era la que no funciono para que puedan ser traducidos posteriormente <-- wes ha salido (Quit: [BX] With a BitchX here and a BitchX there, here a BitchX there a BitchX everywhere a BitchX) GETTEXT_PACKAGE=gturing-2.0 eso, es simplemente una definicion de una variable como es una definicion nuestra necesitamos decirle que la haga visible: AC_SUBST(GETTEXT_PACKAGE) AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE,"$GETTEXT_PACKAGE",[The gettext package]) okas --> Dr_Neo (~Power_of_@irc.cl-339408.terra.cl) ha ingresado en #gnome ahhh AC_DEFINE_UNQUOTED pondra caracteres de escape cuando reemplace el texto en el fondo dice: GETTEXT_PACKAGE definalo con el contenido de "$GETTEXT_PACKAGE" que lo indicamos mas arriba y el mensaje por pantalla será: ahhh The gettext package <-- Dr_Neo (~Power_of_@irc.cl-339408.terra.cl) ha salido de #gnome ahhhh :-) en el config.h quedará así: #define ENABLE_NLS 1 #define HAVE_GETTEXT 1 #define GETTEXT_PACKAGE "gturing-2.0" aaahhhh una consulta german y en nuestro programa principal: #ifdef ENABLE_NLS bindtextdomain (GETTEXT_PACKAGE, GTURING_LOCALEDIR); bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); textdomain (GETTEXT_PACKAGE); #endif ah el GETTEXT_PACKAGE ya sabemos de donde sale justamente era esa mi pregunta :-) del config.h que se genero a partir del configure.in el GTURING_LOCALDIR no es mágico y la plantilla del config.h supngo que sale del config.h.in o no? :-) por ahí dice: -DGTURING_LOCALEDIR=\""$(datadir)/locale"\" que quiere decir, el directorio donde deberá buscar las cadenas de textos típicamente las traducciones de acuerdo a la variable LANG, LC_ALL, etc. jci: si pero el config.in no pertenece al proyecto tambien se genera en forma automatica ah configure.in -> config.h.in -> config.h ah okas aunque configure.in es mucho mas que config.h.in yeps el config.h.in es mas una plantilla el configure.in es otra cosa distinta si jejeje :-) con el configure.in + una plantilla estándar, se genera otra plantilla (config.h.in) que es dependiente de las opciones que definiste en el configure.in es decir, una plantilla personalizada de re pente me he pillado con algunos .in.in jci: si, en el directorio po/ la otra variable que se usa en internacionalizacion es: ALL_LINGUAS="ca cs da de es fr ga" e indica que idomas se encuentran las traducciones ahhh jejeje es conveniente colocarlas en orden alfábetico si quieres añadir un nuevo idioma, simplemente colocas el nombre de la traduccion http://www.linuxjournal.com/article.php?sid=6176 es necesario que esten en orden alfabetico? ojo, esto hará que el programa verifique que los archivos ese para las traducciones ca.po cs.po da.po etc existan dentro del directorio po hay que recordar que aclocal y no solo define sino que busca si los programas necesarios estan instalados --> JuanCri (Enasdo@irc.cl-427014.surnet.cl) ha ingresado en #gnome y donde estan instalados asi por ejemplo si colocamos AC_PROG_INTLTOOL e intltool no está instalado, hasta allí no mas llega el script <-- JuanCri ha salido (Client exited) el ./configure fallará lo cual es la idea indicar por qué ha fallado que otras macros van casi siempre: AM_PROG_LIBTOOL si queremos verificar la existencia de libtool ahhh The `libtool' program provides a standard way to generate both static and shared libraries. It hides the complexities of platform-specific library generation behind an interface that is the same across all platforms supported by libtool. eso hace un chequeo solamente? si, verifica que existan para que se use :-) ahhh :-) AC_ISC_POSIX no me la se :-) pero tiene algo que ver con POSIX :-) AC_PROG_CC nuestro programa esta en C, asi que requerimos lo necesario para compilar en C ah okas AC_STDC_HEADERS verificamos los headers (include) estandares jejeje GNOME_PLATFORM_GNOME_2(yes, force) la mayoria de las macros de AC vienen en el LPU esa es una macro de GNOME ahora bien <-- wheezy ha salido (Quit: [BX] Size DOES matter) puede ser que nuestro programa requiera de alguna biblioteca en particular por ejemplo, que esten las definiciones de limits.h entonces le pedimos que lo verifique: AC_CHECK_HEADER(limits.h) pero eso solo chequea que este en /include? o en algun path especifico? en las rutas estandares /usr/include ah okas AC_CHECK_HEADERS(db_185.h db.h) que verificará? :-) que existan los encabezados db_185.h y db.h jejeje ahora bien puede ser que los encabezados esos se encuentren en otro lugar porque quizas se instalaron en un directorio del usuario que los compilo a mano, etc. para eso se utiliza el parámetro --includedir=DIR C header files [PREFIX/include] en el configure que viene de manera automatica ojo, aclocal, automake, no verifican, solo añaden comandos que permitiran que ./configure verifique ese el que hace la pega aahhhh eso eso eso es lo que no cachaba el configure.in es para decirlo como tiene que hacer el script configure AC_CHECK_TYPE(umode_t, mode_t) alguien me alego no recuerdo donde que el configure.in no era lenguaje de macros :-\ eso te permitirá saber si existen esos tipos ac_check_type chequea los tipos de datos que existan? ah...okas con es un lenguaje, está escrito con macros :-) s/con/no/ ah eso eso tambien podemos definir algunas variables extras por ejemplo, para utilizar en nuestros Makefiles por ejemplo: DISABLE_DEPRECATED_CFLAGS=" \ -DG_DISABLE_DEPRECATED \ -DGDK_DISABLE_DEPRECATED \ -DGDK_PIXBUF_DISABLE_DEPRECATED \ -DGTK_DISABLE_DEPRECATED \ -DGNOME_DISABLE_DEPRECATED \ -DBONOBO_DISABLE_DEPRECATED" eso son espacios y el \ es para indicar que continua en la linea siguiente yeps esas son definiciones para asegurarse que el programa no existen funciones declaradas "deprecated" es decir, que ya no se recomiendan por ejemplo: gtk_signal_connect y g_signal_connet gtk_signal_connect y g_signal_connect la primera se usaba en GTK+ 1.2, pero ahora es deprecated gtk_signal_connect esta deprecada para gtk2, cierto? pfff y se recomienda usar g_signal_connect proxima pregunta muero piola mejor por el movimiento de objetos que hay entre una version y otra si bien es cierto, gtk_signal_connect aun existe en gtk 2.0 no se recomienda pero recomiendan no usarla oye german una consulta salio hace poco el lanzamiento de gnome 2.1.3 entonces, si quieres asegurarte que tu programa está completamente portado a GNOME 2 le indicas las definiones anteriors ah así cuando compiles tu programa y el compilador encuentre un gtk_signal_connect, reclamará que esa funcion no existe y me di cuenta que agregaron hartas cosas, pero le sacaron cuestiones a nautilus (por ejemplo) estás atrasad jci, ya va en 2.1.4 ah jejejeje tonces lo dejo bajando mañana :-) pero no sep... hay muchas cosas que se dieron cuenta que estaban mal el 2.1.2 y 2.1.3 siempre vive cayendo el panel si el unico que me ha andado bien es el 2.0.2 por ejemplo, el manejo de objetos es independiente de la interfaz grafica yeps, eso sip entonces, si quieres construir tus programas para consola y quietes objetos en C, antes tenias que enlazar contra gtk+ lo cual es una tonteria entonces, se movio el sistema de objetos a glib ahhh para facilitar la migracion las funciones se declaran deprecated ahhh weno, conclusion gnome 2.1.3 no me gusto :-( eso significa que para el siguiente gran release (2.2 por ejemplo) estaran obsoletas eso es decir, ya no se encontraran cuando se supondria que saldria el proximo release de 2.2? enero en el calendario por que el movimiento que estan haciendo es como radical no en algunas cosas, como fue nautilus lo dejaron pelaito pa 2.1.3 :-) no tiene tantos chiches como antes limpieza, pero sigamos con configure okas dele no mas profe :-) luego existe pkg-config yeps el que permite buscar las bibliotecas y cabaceras de los programas que queremos instalar que se supone reemplaza a todas las bestias de gnome1.x, cierto? gnome-config, orbit-config y varios? si ah en realidad, es harto mas facil en todo caso, cada programa sigue trayendo sus propios scripts de configuracion pero si tienes pkg-config, mejor usas eso para utilizar pkg-config cierto simplemente usas la macro: PKG_CHECK_MODULES(GTURING, libgnomeui-2.0) que en este caso, verificará si libgnomeui-2.0 se encuentra entre los modulos de pkg-config es el equivalente a: ah okas pkg-config --cflags libgnomeui-2.0 pero solo como ejemplo, porque en estricto rigor: se deben declarar: AC_SUBST(GTURING_CFLAGS) AC_SUBST(GTURING_LIBS) si te das cuenta GTURING_ el primero es el nombre de la variable de verificacion de PKG_CHECK_MODULES y automaticamente define VARIABLE_CFLAGS y VARIABLE_LIBS y asi, podemos definir otras: PKG_CHECK_MODULES(GNETWORK, libgnomeui-2.0 libgnome-2.0 gtk+-2.0 glib-2.0 libglade-2.0) AC_SUBST(GNETWORK_CFLAGS) AC_SUBST(GNETWORK_LIBS) la idea es la misma solo que ahora verifica por mas paquetes ahhh esa las lei recien en gtktalog innecesario a decir verdad, porque libgnomeui-2.0 incluye a las otras, con excepcion de libglade-2.0 osea hubiera bastado con: eso :-) PKG_CHECK_MODULES(GNETWORK, libgnomeui-2.0 libglade-2.0) AC_SUBST(GNETWORK_LIBS) AC_SUBST(GNETWORK_CFLAGS) ojo, vayan recordando las variables que hemos guardado, porque luego las usaremos si se dan cuenta AC_CHECK_HEADER(limits.h) verifica que exista pero en ocasiones podemos querer que compile igual el programa pero con o sin alguna opcion especial por ejemplo: AM_CONDITIONAL(HAVE_LIBZVT, test "x$have_zvt" = "xyes") si se encuentra LIBZVT entonces haga lo que tenga que hacer sino, no importa, no se incluye ese modulo se entiende? yeah para explicar un poco mas puedo tener un programa que tiene interfaz ncurses y gtk+ si no es encuentra instalado gtk+, entonces solo compilo la interfaz ncurses si estan instalados los 2, entonces compilo los 2 aun así, en esa macro hay cosas medio nebulosas voy a escribirlo completo: PKG_CHECK_MODULES(ZVT, libzvt-2.0, have_zvt=yes, have_zvt=no) AM_CONDITIONAL(HAVE_LIBZVT, test "x$have_zvt" = "xyes") AC_SUBST(ZVT_CFLAGS) AC_SUBST(ZVT_LIBS) hmmm si se dan cuenta, estou empleando 4 parámetros en la macro PKG_CHECK_MODULES los 2 ultimos son opcionales shau monos <-- halley ha salido (Quit: ipv6.ubiobio.cl) el tercer argumento es "realizar una acción en caso de ser afirmativo" se encuentra libzvt-2.0 en este caso y define la variable have_zvt=yes de la misma forma que se hace en el shell con un case supongo no simplemente la asigna ah okas comprueba, si se encuentra ==> have_zvt=yes, sino have_zvt=no pero eso no es suficiente en alguna parte de nuestro programa queremos algo coo if HAVE_VFSMODULE if HAVE_HAVE_LIBZVT eso era, error en el copy/paste pero para poder hacer eso, tenemos que tener definido HAVE_LIBZVT con un valor de verdad eso se declara con: --> Muad-Dib (eric@irc.cl-316518.terra.cl) ha ingresado en #gnome --- vmlinuz fija modos [#gnome +o Muad-Dib] AM_CONDITIONAL(HAVE_LIBZVT, test "x$have_zvt" = "xyes") jjeje eso es un vulgar "test" que existe en el shell ah aqui hay un truco la comparacion debiera ser: test "$have_zvt" = "yes" eso devuelve un valor de verdad pero: si por A, B o C motivo, $have_zvt no estuviera definido habrá un error porque no es posible comparar: ahhhh "" con "yes" :-) entonces se le añade algo comun en ambos lados test "x$have_zvt" = "xyes" es decir, se asegura en al menos habrá una letra en cada lado aahhh por eso el x donde el lado peligroso es donde está la variable que pille hoy holñas claro que pensandolo bien en este caso pareciera medio rebuscado ya que PKG_CHECK_MODULES lo define en ambos caso (si y no) ... pero pongamos un ejemplo mas entretenido queremos verificar si el programa ping se encuentra instalado y en donde y nos interesa tener guardado el lugar donde se encuentra así, en nuestro programa podremos llamarlo así: gchar *cmd = PING_PROGRAM; puede ser que ping, se encuentre instalado cualquier parte y tal vez no este en la ruta definida en el ambiente del usuario que lo compila entonces, queremos darle la opcion al usuario para que pueda ingresarlo tipicamente con --with-ping=/opt/bin/ping ... o algo asi se entiende lo que queremos hacer? yeps entonces manos a la obra: en caso que el configure no lo pille automaticamente claro AC_ARG_WITH(ping, [ --with-ping=PATH Where ping is.]) eso creara la opcion en el configure yeps si se ejecuta ./configure --help aparecerá en alguna parte: --with-ping=PATH Where ping is. --with-ping algo ah jejejeje y una consulta es decir, el usuario podrá llamarlo como: como el configure --help aparece tabulado ./configure --with-ping=/home/usuario/bin/ping o es automagico el tabulado? jci: el primer parámetro si ah okas el contenido no, en mi caso Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-gnu-ld assume the C compiler uses GNU ld default=no --with-pic try to use only PIC/non-PIC objects default=use both --with-ping=PATH Where ping is. es algo que debo analizar, pero no me quita el sueño jejeejej okas no prob <-- Muad-Dib ha salido (Quit: Client Exiting) con tal que se vea :-) AC_ARG_WITH(ping, [ --with-ping=PATH Where ping is.]) alli estabamos yeps tenemos 2 argumentos el segundo es el comando que aparecera en la ayuda quise decir: el segundo es la ayuda del comando que aparecerá okas el primero es el nombre de la variable pero no es cualquier nombre, es del tipo with_ping okas así, si hubieramos colocado: AC_ARG_WITH(chanchito, [ --with-ping=PATH Where ping is.]) para saber su valor, debieramos preguntar por with_chanchito pero como es una variable, como $with_chanchito que es lo que haremos ahora: ah okas determinar si el usuario agregó algo: he aquí el truco nuevamente: if test "x$with_ping" = "x" ; then esto es shell y lo que preguntamos: "el usuario *NO* ingresó nada" para que sea verdad, $with_ping debe ser vació vacío sólo en ese caso "x$with_ping" será igual a "x" ahh verdad ahora se nota la utilidad del truco por que es medio complejo comparar valores vacios de ahi el uso de la x entonces si el usuario no ingreso eso, trataremos de buscarlo AC_PATH_PROG(PING_PROGRAM, ping,, $PATH:/usr/etc:/usr/sbin) ahhh lo que hace, es buscar un programa en la ruta pero esa var $PATH es la variable de ambiente PATH? para ello utilizará PING_PROGRAM para dejar el valor si, es del ambiente ping es el programa a buscar ah... el tercer argumento está vació, y es por si queremos dejar algo allí en caso que sea falsa la búsqueda y el último parámetro es la ruta donde buscar ah okas podría estar vacía también, y en ese caso solo buscará en el PATH ahhh pero aquí añadí otros 2 directorios algunos Unix tiene algunos de estos ejecutables bajo /usr/etc ah okas o bien /usr/sbin, que normalmente no se encuentra en la ruta de todos los usuarios luego, debemos verificar que PING_PROGRAM tiene algun valor es decir, saber como le fue en la busqueda a AC_PATH_PROG y que hacemos? if test "x$PING_PROGRAM" != "x" ; then aahhhhhh PING_PROGRAM puede tener cualquier cosa poblamos la variable no sabemos como ping_program o no? :-\ si, tenemos que poblarla o mas bien, declarar el #define correspondiente en config.h aahhh eso, eso es decir if test "x$PING_PROGRAM" != "x" ; then verifica si PING_PROGRAM tiene algun valor porque se pide que sea != "x" yeps AC_DEFINE_UNQUOTED(PING_PROGRAM, "$PING_PROGRAM", [The ping program]) --> denys (denys@irc.cl-362436.terra.cl) ha ingresado en #gnome y en nuestro config.h aparecerá: #define PING_PROGRAM "/bin/ping" #define PING_.... eso, eso :-= :-) no está completo: una consulta /* The ping program */ #define PING_PROGRAM "/bin/ping" antes de seguir es que xchat interpretó el / si la macro es UNQUOTED por que aparece con comillas en el define? :-) quiere decir lo siguiente: que pasa si la valor de la variable es: /bin/"ping? quedaría mal el define #define PING_PROGRAM "/bin/"ping" aaahhh okas lo cual es un error de sintaxis o sea eso el unquoted es para que se preocupe de eso el resultado de ac_define_unquoted es sacar las comillas del resultado :-) finalmente quedará así: AC_ARG_WITH(ping, [ --with-ping=PATH Where ping is.]) if test "x$with_ping" = "x" ; then AC_PATH_PROG(PING_PROGRAM, ping,, $PATH:/usr/etc:/usr/sbin) if test "x$PING_PROGRAM" != "x" ; then AC_DEFINE_UNQUOTED(PING_PROGRAM, "$PING_PROGRAM", [The ping program]) fi jejeje else AC_DEFINE_UNQUOTED(PING_PROGRAM, "$with_ping", [The ping program]) fi <-- pingu ha salido (Ping timeout: 180 seconds) AM_CONDITIONAL(HAVE_PING, test "x$PING_PROGRAM" != "x") ojo: en el else va: AC_DEFINE_UNQUOTED(PING_PROGRAM, "$with_ping", [The ping program]) * ReX is back (gone 02:39:18) eso es eso ya como que entiendo el autoconf en el caso que el usuario *SI* haya colocado --with-ping=/blah/bhal/ping grax german :-) dejame terminar que estoy inspirado okas, okas hi hiz te imaginaras para que es el: AM_CONDITIONAL(HAVE_PING, test "x$PING_PROGRAM" != "x") define HAVE_PING para poder preguntar posteriormente si hay ping, se compila el modulo que analiza el ping yeps uff, mis vecinos tienen una fiesta, y tienen sus cumbias a toda raja hahah de lo contrario, construye el resto me voy a acostar en otra pieza toi cachando falta lo importante: AC_CONFIG_FILES([ Makefile po/Makefile.in src/Makefile pixmaps/Makefile tapes/Makefile help/Makefile help/C/Makefile ]) eso es lo que finalmente construye ah okas construye el Makefile en el directorio rail del proyecto los los Makefiles de los otros directorios yo cacho que de aqui cuando me desconecte, de cabeza a GNU Autoconf, Automake y Libtool :-) si te das cuenta, en po/ hay un Makefile.in yeps es decir, lo crea a partir de Makefile.in.in los otros los crea a partir de un Makefile.in y estos se crean a partir de un Makefile.am jeje opcionalmente podemos terminar con la siguiente macro: AC_OUTPUT echo " Configuration: Source code location: ${srcdir} Compiler: ${CC} Flags: ${CFLAGS} " ah que nos permite imprimir por pantalla cualquier cosa para mostrar las opciones o cualquier otro cachibache en este caso para decirle al usuario que opciones finalmente se usaran pero perfectamente podria ser: echo " que no muchos configure muestran :-) Esta es una version de desarrollo, no la use sino sabe lo que hace " no es obligacion hacerlo ah okas ya vimos el configure.in queda la anatomia de Makefile.am que es mas pequeño por ejemplo: SUBDIRS = pixmaps tapes po src help eso indica que tiene que hacer Make make en esos subdirectorios tipicamente aparece: "Entering to ..." y luego.... "Leaving ..." cuando uno ejecuta make eso de saber a donde entrar, lo saca de ahí un error que uno comete siempre cuando parte es ah... pensar que con colocarlo en AC_CONFIG_FILES es suficiente y no es así lo unico que hace esa macro, es que configure creará los Makefiles correspondientes en eso directorios pero el Makefile.am principal no sabe a donde tiene que meterse, no lo hará si al final, quien hace el trabajo es "make" jejej si estamos en un directorio, como src, donde no hay subdirectorios entonces se define vacío SUBDIRS = otras variables en el Makefile.am: bin_PROGRAMS = gturing eso es, como se llamará el ejecutable ah okas es decir, cuando compile todo, el gcc dirá: gcc -o gturing .... ah jejeje la variable *TIENE* que llamarse bin_PROGRAMS son estandares ah okas otras cosas a definir: INCLUDES = \ -DGTURING_LOCALEDIR=\""$(datadir)/locale"\" \ @GTURING_CFLAGS@ ah las arrobas eso oh! que encontramos acá jejeej primero: -DGTURING_LOCALEDIR=\""$(datadir)/locale"\" el que usamos magicamente al principio cuando veiamos GETTEXT pa que voy a preguntar si ya viene la respuesta :-) aqui está el define y el @GTURING_CFLAGS@ de adonde salió? PKG_CHECK_MODULES(GTURING, libgnomeui-2.0) jejejee AC_SUBST(GTURING_CFLAGS) del configure :-) de allí salió cuando definimos esas variables entonces, de lo que resulte de ejecutar: pkg-config --cflags libgnomeui-2.0 tambien podriamos poner: INCLUDES = \ -I$(includedir) \ -DGPING_LOCALEDIR=\""$(datadir)/locale"\" \ -DDATADIR=\""$(dialogdir)/"\" \ @GNETWORK_CFLAGS@ si se dan cuenta, son varios -D que son equivalentes a #define en un programa pero, que $(includedir) u $(datadir)? ah no me lo van a creer cuando ejecutan ./configure --help del configure? por allí dice: --with-includes-dir? --datadir=DIR read-only architecture-independent data [PREFIX/share] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] eso :-) alli estan aaaahhhhhh y tiene valores predeterminados si no le colocan nada, probablemente será /usr/local/share (datadir) yeps y /usr/local/include /(includedir) por que asume el prefix como /usr/local o no¿? se puede cambiar en el configure yeps cuando le das --prefix= --prefix :-) pero se entiende que las compilaciones no van en /bin yeps si lo vas a empaquetar si, pero sino, no son parte de la distro ah claro y entramos a un plano mas filosófico del asunto volvamos se supone que hay que construir un arbol falso cierto? para lo que es empaquetamiento cuando estas programando si okas ahhh... si por que he visto en algunos rpms con fakeroot se puede hacer en debian por ejemplo, que asume un RPM_ROOT ah si para eso era fakeroot!!! no cachaba :-) hay que tener algunos cuidados; INCLUDES = \ -I$(includedir) \ -DGPING_LOCALEDIR=\""$(datadir)/locale"\" \ -DDATADIR=\""$(dialogdir)/"\" \ @GNETWORK_CFLAGS@ el @GNETWORK_CFLAGS@ debe ir al final eventualmente podría ser *vacío* y si está antes, podría dar un error en el Makefile y el usuario estaría confundido, y no queremos eso ah okas que mas tenemos: gturing_LDADD = @GTURING_LIBS@ lo mismo tambien pudo ser escrito como: LDADD = $(GTURING_LIBS) pero es mejor el primero es mas propio del programa un cuidado muy especial: por qué se llama "gturing_LDADD" y no se llama "pepito_LDADD"? porque en el configure.in pusimos: AC_INIT([gturing],[0.1.1],[gpoo@ubiobio.cl]) aaaaahhhhh AM_INIT_AUTOMAKE(AC_PACKAGE_NAME,[0.1.1]) entonces, le estamos diciendo que todo comenzará con gturing_ nos damos cuenta que todo tiene relación aaahhh :-) y bien, nos falta lo mas importante que queremos compilar? gturing_SOURCES = \ gturing.c \ gturing.h \ turing.h \ turing.c \ graph_editor.c \ graph_editor.h \ turing_table_editor.c \ turing_table_editor.h ah nuevamente gturing_ los archivos de guentes fuentes exacto aahhh y solito se encarga del resto de alli toma los fuentes si quiero agregar un archivo mas, lo agrego ahi :-) y finalmente lo transforma en gturing, de acuerdo a bin_PROGRAMS ah okas jci, exacto es mas ahhh está hecho de tal forma, que si lo agregas al Makefile.am y ya tiene el Makefile hecho, al ejecutar $ make automaticamente ejecutara automake jejejjee o sea volvera a construir el Makefile tiene su ciencia! y luego compilarña ohhh :-) * jci mesmerized :-) y no tienes para que ejecutar nuevamente ./autogen.sh ni ./configure nuevamente ah okas lo hace por ti cuando está bien hecho, eso si ah okas tambien se pueden definir cosas extras por ejemplo, es logico que el binario se instale asi que bin_PROGRAMS es candidato a instalarse cuando se ejecute make install pero que sucede con las interfaces en glade? son necesarias igual que las imagenes o cualquier otra cosa que queramos que se instale okas en gnome-netinfo defini lo siquiente: dialogdir = $(datadir)/$(PACKAGE)/dialogs dialog_DATA = gnome-netinfo.glade ojo: el "dialog" al principio es arbitrario pudo ser: pepitodir = ... ah okas pepito_DATA = ... --> jrami (~jaime@eledificio.cl) ha ingresado en #gnome lo que buscara es a lo que esta antes de "dir" le buscara su pareja en "_DATA" en este caso: dialogdir = $(datadir)/$(PACKAGE)/dialogs ajap si el prefix es /opt se instalara en /opt/share/gnome-network/dialogs okas por /opt/share es $(datadir) gnome-netork es $(PACKAGE) y dialogs, porque lo coloque en bruto allí jejeje invierno: cual es la pagina con las listas de la ubb? ReX: http://www.ubiobio.cl/mailman/listinfo luego tenía: dialog_DATA = gnome-netinfo.glade alli puedo colocar mas archivos okas aahhhh :-) que estarán relacionados a dialogdir los archivos donde sacar las interfaces ... :-) si por eso en: INCLUDES = \ -I$(includedir) \ -DGPING_LOCALEDIR=\""$(datadir)/locale"\" \ -DDATADIR=\""$(dialogdir)/"\" \ @GNETWORK_CFLAGS@ hay un define que dice: eso es lo que siempre me complica...colocar los archivos -DDATADIR=\""$(dialogdir)/"\" \ ahh por que defino eso? pasando una variable para decir de donde sacar los archivos :-) en alguna parte del programa tengo: const gchar *dialog = DATADIR "gnome-netinfo.glade"; es decir, *dialog apunta a "/opt/share/gnome-network/dialogs/gnome-netinfo.glade" jejejee :-) simple y clean y siempre buscará en el lugar correcto de la instalación eso tiene un contra, eso sí si modifico la interfaz, tengo que instalarla en ese directorio de lo contrario el programa encontrará la antigua, se entiende? yeps :-) en realidad, eso era lo que me complicaba que pasa si queremos monos? pixmapdir = $(datadir)/pixmaps pixmap_DATA = en este caso, no tengo imagenes pero podria tenerlas y alli las colocare okas y se instalaran en /opt/share/pixmaps siempre que el prefix sea /opt como lo indique como ejemplo más arriba pero, donde está la magia? como en esto no hay magia, hay que definirlo: hmmm EXTRA_DIST = $(pixmap_DATA) gnome-netinfo.desktop \ $(dialog_DATA) EXTRA_DIST es para indicarle los archivos que son extras a los ejecutables ah okas pero que son de la distribucion del paquete, cierto? en este caso, toma los archivos en $(pixmap_DATA), $(dialog_DATA), etc. si, son de la distribucion del paquete es decir, nos interesa que se instalen ah okas finalmente podemos colocar: (repito, al final) install-data-local: @$(NORMAL_INSTALL) que es una regla que indica como instalar los datos aqui podemos colocar algun "pseudo script" que funcione en make okas en este caso, no es necesario en que caso seria tener un pseudo script? que quieras ejecutar alguna cosa como cambio de permisos ah okas o algun detalle particular antes que se me olvide <-- sourcer ha salido (Quit: BitchX: for distribution only with a new PC) eso es todo lo de Makefile.am lo de internacionalizacion tampoco es magico jejejeej como sabe intltool de donde sacar las cadenas a traducir? hasta el momento hemos dicho que queremos usarlos de los POTFILES? exacto jejeje! :-) pero del POTFILES.in si queremos añadir un nuevo archivo, lo indicamos alli si borramos alguno, es conveniente que tambien lo saquemos de alli bueno okas ahora estamos en condiciones de ejecutar make make install jejeje pero como sacamos un tar.gz? ahora la consulta del millon!!! podriamos hacerlo a lo bruto --> sourcer (~sourcer@irc.cl-363090.terra.cl) ha ingresado en #gnome --- vmlinuz fija modos [#gnome +o sourcer] [sourcer] My name is Dump, Core Dump antes del tar.gz una consultilla german pero la forma elegante de hacerlo, y la que se recomienda es: make distcheck donde saca la lista de permisos (0644, etc) ¿? al hacer make install o depende solamente del tipo de archivo? es que al hacer make install depende del tipo de archivo algunas veces he visto lo que es _DATA es 0644 install blabla directorio ah vale tambien herencia del .am :-) es que se usa el script install okas por ejemplo, un Makefile generado tendrá los siguiente: INSTALL = /home/gpoo/bin/install -c INSTALL_PROGRAM = ${INSTALL} $(AM_INSTALL_PROGRAM_FLAGS) INSTALL_DATA = ${INSTALL} -m 644 INSTALL_SCRIPT = ${INSTALL} si te das cuenta: INSTALL_DATA = ${INSTALL} -m 644 aahhhh alli se indican permisos :-) para la parte _DATA ah okas ya...okas el make distcheck :-) es un poco mas desgraciado muchas cosas funciona con make y make install uta que agarraste papa con autoconf/automake invierno pero fallan con make distcheck make distcheck verifica que todo este correcto y con AM_MAINTAINER_MODE añade -Werror aaahhh es decir, si tu programa arroja algun warning, lo toma como error y detiene el proceso hasta que saques ese warning aahhh nada de entregar cosas medias cuchufletas jejeje sourcer: aprovechando la inspiracion y bueno, si tienen consultas... jejejee yo quede liz taylor :-) esta es la explicacion que siempre quiso el juanjo espero no haberlos aburrido jejeje too lo contrario :-) grax german, nuevamente fueron 2 horas 20 aprox