Charlas informales de GNOME Chile: automake/autoconf

Germán Poo Caamaño (invierno)

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
y tambien el de gnome-network
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 <config.h>
#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 :-)

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
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
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

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
y donde estan instalados
asi por ejemplo
si colocamos AC_PROG_INTLTOOL
e intltool no está instalado, hasta allí no mas llega el script
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
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 <prefix>/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

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:
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
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])

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
AM_CONDITIONAL(HAVE_PING, test "x$PING_PROGRAM" != "x")
ojo:
en el else va:
       AC_DEFINE_UNQUOTED(PING_PROGRAM, "$with_ping", [The ping program])

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
:-)

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 = ...
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
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] 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 <permisos> 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