| 1 |
chiguire 07/09/17 10:55:41 |
| 2 |
|
| 3 |
Added: autotools-practices.xml |
| 4 |
Log: |
| 5 |
new translation, special thx to anon contributor |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/es/articles/autotools-practices.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/autotools-practices.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/autotools-practices.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: autotools-practices.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version='1.0' encoding="UTF-8"?> |
| 16 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 17 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/autotools-practices.xml,v 1.1 2007/09/17 10:55:41 chiguire Exp $ --> |
| 18 |
|
| 19 |
<guide link="/doc/es/articles/autotools-practices.xml"> |
| 20 |
<title>Las mejores prácticas con autotools</title> |
| 21 |
|
| 22 |
<author title="Autor"> |
| 23 |
<mail link="flameeyes@g.o">Diego Pettenò</mail> |
| 24 |
</author> |
| 25 |
|
| 26 |
<author title="Traductor"> |
| 27 |
<mail link="LinuxBlues@×××××××××.org">LinuxBlues</mail> |
| 28 |
</author> |
| 29 |
|
| 30 |
<abstract> |
| 31 |
Este artículo cubre algunos de los errores más comunes que se cometen al usar |
| 32 |
autotools y muestra cómo obtener mejores resultados. |
| 33 |
</abstract> |
| 34 |
|
| 35 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 36 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 37 |
<license/> |
| 38 |
|
| 39 |
<version>1.0</version> |
| 40 |
<date>2005-12-16</date> |
| 41 |
|
| 42 |
<chapter> |
| 43 |
<title>Las mejores prácticas con autotools</title> |
| 44 |
<section> |
| 45 |
<body> |
| 46 |
|
| 47 |
<p> |
| 48 |
El núcleo de la cadena de compilación GNU -- el conjunto de |
| 49 |
herramientas usadas para construir paquetes de software GNU -- es lo |
| 50 |
que se conoce como "autotools" un término que alude a los programas |
| 51 |
autoconf y automake, así como a libtool, autoheader, pkg-config y, a |
| 52 |
veces, gettext. Estas herramientas permiten compilar software GNU en |
| 53 |
una amplia variedad de plataformas, y en sistemas operativos Unix o de |
| 54 |
tipo Unix, proporcionando a los desarrolladores un marco para |
| 55 |
comprobar la presencia de librerías, funciones y herramientas que |
| 56 |
quieran usar. Mientras que las autotools son extraordinarias en manos |
| 57 |
de un desarrollador con experiencia, pueden ser demasiado para quien |
| 58 |
las usa por primera vez, y no es tan raro encontrar paquetes |
| 59 |
proporcionados con soporte para autotools que a pesar de funcionar |
| 60 |
está mal hecho. Este artículo cubre algunos de los errores más comunes |
| 61 |
que se cometen al usar autotools y algunas formas para alcanzar |
| 62 |
mejores resultados. |
| 63 |
</p> |
| 64 |
|
| 65 |
<p> |
| 66 |
A pesar de la opinión que cualquiera pueda tener acerca de ellas, |
| 67 |
actualmente no disponemos de ninguna alternativa válida a |
| 68 |
autotools. Proyectos tales como Scons no son tan válidos en cualquier |
| 69 |
plataforma como autotools y no envuelven el suficiente conocimiento |
| 70 |
como para ser útiles de momento. Tenemos montones de comprobaciones |
| 71 |
automáticas con autotools, y muchas librerías vienen con otra librería |
| 72 |
m4 para poder comprobar su presencia. |
| 73 |
</p> |
| 74 |
|
| 75 |
<p> |
| 76 |
La estructura básica de un proyecto elaborado con autotools es |
| 77 |
simple. Autoconf toma la ayuda de un archivo <path>aclocal.m4</path> |
| 78 |
(creado por aclocal usando las librerías m4 en su ruta de búsqueda y |
| 79 |
del archivo <path>acinclude.m4 </path>) para crear el archivo |
| 80 |
<path>configure.ac</path> (anteriormente <path> configure.in</path>) y |
| 81 |
lo transforman en el archivo de comandos "configure". Para cada |
| 82 |
directorio que se encuentre en el mismo debe existir un <path> |
| 83 |
Makefile.am</path> que automake usa para crear las plantillas |
| 84 |
Makefile.in. Las plantillas Makefile.in son procesadas por la macro |
| 85 |
<path>configure</path> que las transforma en Makefiles reales. Se |
| 86 |
puede evitar usar automake escribiendo nuestros propios archivos |
| 87 |
Makefile.in, pero esto es demasiado complejo y se pierden algunas |
| 88 |
características de las autotools. |
| 89 |
</p> |
| 90 |
|
| 91 |
<p> |
| 92 |
En un archivo <path>configure.ac</path> se pueden usar macros que |
| 93 |
definimos nosotros mismos, aquellas que proporcionan por defecto |
| 94 |
autoconf y aclocal, o macros externas proporcionadas por otros |
| 95 |
paquetes, por ejemplo. En este caso, aclocal creará el archivo |
| 96 |
<path>aclocal.m4</path> añadiendo los archivos de librerías que |
| 97 |
encuentra en las librerías del sistema con las macros definidas; este |
| 98 |
es un paso crítico para tener un proyecto con autotools que funcione |
| 99 |
correctamente, como veremos en un momento. |
| 100 |
</p> |
| 101 |
|
| 102 |
<p> |
| 103 |
Un <path>Makefile.am</path> es principalmente una declaración de |
| 104 |
intenciones: Se pueden rellenar algunas variables de objetivos con el |
| 105 |
nombre de los objetivos que pretendemos construir. Estas variables se |
| 106 |
encuentran estructuradas en un formato del tipo lugarainstalar |
| 107 |
TIPODEOBJETIVO. El lugar es la localización en un sistema de ficheros |
| 108 |
jerárquico Unix (bin, lib, include, ...), una palabra clave no usada |
| 109 |
que puede ser definida con una ruta arbitraria (usando la variable |
| 110 |
keyworddir), o la palabra clave especial noinst que apunta a los |
| 111 |
objetivos que no necesitan ser instalados (cabeceras privadas por |
| 112 |
ejemplo o librerías estáticas usadas durante la construcción). Después |
| 113 |
de denominar al objetivo, se puede usar el nombre (reemplazando los |
| 114 |
puntos por caracteres de subrayado) como el prefijo para las variables |
| 115 |
que afectan a su construcción. De esta forma se pueden proporcionar |
| 116 |
variables CFLAGS, LDFLAGS y LDADD especiales usadas durante la |
| 117 |
construcción de un único objetivo, en lugar de cambiarlas para todos |
| 118 |
los objetivos. Se pueden usar también variables recogidas en la fase |
| 119 |
configure, si se le pasan a la macro AC_SUBST en <path>configure.ac |
| 120 |
</path>, para que puedan ser reemplazadas en los makefiles. Además, |
| 121 |
aunque definir las CFLAGS y LDFLAGS en base al objetivo es muy útil, |
| 122 |
añadir parámetros estáticos en el Makefile.am no es adecuado para |
| 123 |
obtener una mayor portabilidad, dado que no puede saberse de antemano |
| 124 |
si el compilador que se está usando las soporta, o si realmente se |
| 125 |
necesitan (-ldl indicado en las LDFLAGS es un buen ejemplo de un |
| 126 |
parámetro necesario en Linux pero no en FreeBSD); en dichos casos, se |
| 127 |
debe usar <path>configure.ac</path> para añadir dichos parámetros. |
| 128 |
</p> |
| 129 |
|
| 130 |
<p> |
| 131 |
Las macros más frecuentemente usadas en configure.ac son |
| 132 |
AC_CHECK_HEADERS, AC_CHECK_FUNCS, y AC_CHECK_LIB, que comprueban |
| 133 |
respectivamente la presencia de, algunos archivos de cabeceras, |
| 134 |
algunas funciones en librerías, y una librería concreta (que |
| 135 |
proporciona una función específica). Son importantes para la |
| 136 |
portabilidad dado que proporcionan una forma de comprobar qué |
| 137 |
cabeceras están presentes y cuáles no (por ejemplo, cabeceras del |
| 138 |
sistema que están ubicadas de forma diferente en diferentes sistemas |
| 139 |
operativos), y para comprobar si una función está presente en una |
| 140 |
librería del sistema (asprintf() no está en OpenBSD por ejemplo, |
| 141 |
mientras que sí está en la librería GNU C y FreeBSD), y finalmente |
| 142 |
para comprobar la presencia de una librería de terceros o para ver si |
| 143 |
un enlace específico a una librería es necesario para obtener |
| 144 |
determinadas funciones (por ejemplo, la función dlopen() está en la |
| 145 |
librería libdl en los sistemas GNU, mientras que se proporciona en la |
| 146 |
librería C del sistema en FreeBSD). |
| 147 |
</p> |
| 148 |
|
| 149 |
<p> |
| 150 |
Además de comprobar la presencia o ausencia de funciones o cabeceras |
| 151 |
(y a veces de librerías) se suele necesitar habitualmente cambiar la |
| 152 |
ruta del código (para evitar el uso de funciones que no se encuentran, |
| 153 |
o para encontrar otras que las reemplacen, por ejemplo). Autoconf se |
| 154 |
encuentra muy a menudo emparejado con otra herramienta, autoheader, |
| 155 |
que crea una plantilla <path>config.h.in</path>, usada por el archivo |
| 156 |
de comandos configure para crear una cabecera <path> config.h</path> |
| 157 |
donde se definen macros del preprocesador de la forma HAVE_funcióndada |
| 158 |
o HAVE_cabeceradada_H que pueden comprobarse con las directivas |
| 159 |
#ifdef/#ifndef dentro del código fuente de un programa en C o C++ para |
| 160 |
modificar el código de acuerdo con las características presentes. |
| 161 |
</p> |
| 162 |
|
| 163 |
<p> |
| 164 |
He aquí algunas practicas que es necesario tener presentes para crear |
| 165 |
el código más portable posible con autotools. |
| 166 |
</p> |
| 167 |
|
| 168 |
<p> |
| 169 |
<b>el archivo de cabecera config.h debe considerarse un archivo de |
| 170 |
cabecera interna</b>, por lo que deberá ser usado únicamente por el |
| 171 |
paquete que lo ha creado. Se debe evitar editar la plantilla |
| 172 |
<path>config.h.in</path> para añadir nuestro código en ella, dado que |
| 173 |
ello requerirá actualizarlo manualmente de acuerdo con el |
| 174 |
<path>configure.ac</path> que estamos escribiendo. |
| 175 |
</p> |
| 176 |
|
| 177 |
<p> |
| 178 |
Desafortunadamente, algunos proyectos, como Net-SNMP, exportan esta |
| 179 |
cabecera con las cabeceras de otras librerías, lo cual requiere que |
| 180 |
cualquier proyecto que use sus librerías deba incluirlas (o |
| 181 |
proporcionar su propia copia de las estructuras internas de |
| 182 |
Net-SNMP). Esto es un gran inconveniente, dado que la estructura de la |
| 183 |
librería de un proyecto con autotools debe ser invisible para el |
| 184 |
software que la esté utilizando (que puede no usar autotools en |
| 185 |
absoluto). Además, los cambios en el comportamiento de las autotools |
| 186 |
no son nada raro, por lo que pueden haber dos comprobaciones idénticas |
| 187 |
con diferentes resultados dependiendo de la forma en la que se |
| 188 |
ejecuten. Si se necesitan definir nuestros propios envoltorios o |
| 189 |
reemplazos en el caso de que algo no se encuentre en el entorno para |
| 190 |
el que estamos compilando, debe hacerse en cabeceras privadas que no |
| 191 |
se instalen (declaradas como noinst_HEADERS en el archivo |
| 192 |
<path>Makefile.am </path>). |
| 193 |
</p> |
| 194 |
|
| 195 |
<p> |
| 196 |
<b>Proporcionar siempre los archivos m4 que se hayan usado</b>. Dado |
| 197 |
que las autotools se han usado durante años, muchos paquetes (por |
| 198 |
ejemplo librerías) que pueden ser reutilizados por otros programas, |
| 199 |
proporcionan un archivo de librería m4 en |
| 200 |
<path>/usr/share/aclocal</path> que hace posible comprobar su |
| 201 |
presencia (por ejemplo, al usar las macros -config) con una simple |
| 202 |
llamada en una macro. Estos archivos los usa aclocal para crear el |
| 203 |
archivo <path> aclocal.m4</path>, y están presentes en los sistemas de |
| 204 |
los desarrolladores donde aclocal se ejecuta para crear la revisión o |
| 205 |
versión, pero cuando se trata de dependencias opcionales, pueden no |
| 206 |
estar en los sistemas de los usuarios. Aunque esto no constituye |
| 207 |
ningún problema, dado que los usuarios raramente ejecutan aclocal, es |
| 208 |
un serio problema en distribuciones basadas en código fuente como |
| 209 |
Gentoo, donde a veces es necesario crear parches para Makefile.am o |
| 210 |
<path>configure.ac</path> y después volver a ejecutar autoconf sin |
| 211 |
tener todas las dependencias opcionales instaladas (o teniendo |
| 212 |
versiones diferentes, que pueden ser incompatibles, o tener errores, |
| 213 |
del mismo archivo m4). |
| 214 |
</p> |
| 215 |
|
| 216 |
<p> |
| 217 |
Para evitar este problema, debe crearse un subdirectorio m4 en el |
| 218 |
directorio del paquete y añadir posteriormente los archivos de |
| 219 |
librería m4 que se estén utilizando. Después es necesario llamar a |
| 220 |
aclocal con las opciones aclocal -I m4 para buscar en ese directorio |
| 221 |
antes que en el de librerías del sistema. Entonces podemos elegir si |
| 222 |
poner ese directorio bajo control de revisión (CVS, SVN, o cualquier |
| 223 |
otro que se esté usando) o crearlo únicamente para las revisiones. El |
| 224 |
segundo caso es el mínimo requisito indispensable para un paquete. Con |
| 225 |
ello minimizamos la cantidad de código que necesita estar bajo control |
| 226 |
de revisión y asegura que siempre se estará usando la última versión |
| 227 |
m4, aunque tiene el inconveniente de que cualquiera que compruebe |
| 228 |
nuestro repositorio no será capaz de ejecutar autoconf sin obtener un |
| 229 |
tarball de la revisión para obtener el m4 del mismo (y con ello podría |
| 230 |
no funcionar, dado que hemos podido actualizar el configure.ac para |
| 231 |
ajustarse a alguna nueva macro o añadido más dependencias). Por otra |
| 232 |
parte, poner el directorio m4 bajo control de revisión a veces tienta |
| 233 |
a los desarrolladores a cambiar las macros para ajustarlas a sus |
| 234 |
necesidades. Aunque parece muy lógico, dado que los archivos m4 están |
| 235 |
bajo nuestro control de revisión, causará trastornos a muchos |
| 236 |
mantenedores de paquetes, dado que a veces las nuevas versiones de los |
| 237 |
archivos m4 corrigen errores o soportan nuevas opciones y rutas de |
| 238 |
instalación (por ejemplo, configuraciones multilib), y tener archivos |
| 239 |
m4 modificados hace imposible reemplazarlos con las nuevas versiones |
| 240 |
sin más. Lo cual también significa que cuando se actualiza un archivo |
| 241 |
m4 se deben rehacer todas las modificaciones con respecto al original. |
| 242 |
</p> |
| 243 |
|
| 244 |
<p> |
| 245 |
Los archivos m4 son siempre un problema con el que trabajar. Pueden |
| 246 |
replicar casi el mismo código de librería en librería (dependiendo de |
| 247 |
la forma en que necesitemos proporcionar las CFLAGS/LDFLAGS: con |
| 248 |
comprobaciones o con una macro -config). Para evitar este problema los |
| 249 |
proyectos GNOME y FreeDesktop desarrollaron una herramienta denominada |
| 250 |
pkg-config, que proporciona tanto un binario ejecutable como un |
| 251 |
archivo m4 para incluirlo en los archivos configure.ac, y permite a |
| 252 |
los desarrolladores comprobar la presencia de una librería dada (y/o |
| 253 |
paquete), suponiendo que el paquete haya instalado un archivo de datos |
| 254 |
.pc de pkg-config. Esta solución hace mucho más simple el trabajo de |
| 255 |
mantener los archivos de comandos configure.ac, y requiere un tiempo |
| 256 |
mucho menor de procesamiento mientras se ejecuta la macro configure, |
| 257 |
dado que usa la información proporcionada por el paquete instalado en |
| 258 |
lugar de intentarlo si es que se encuentra presente. Por otra parte, |
| 259 |
esta solución significa que cualquier error que cometa un |
| 260 |
desarrollador con respecto a una dependencia puede dañar el programa |
| 261 |
del usuario, dado que únicamente retocan los parámetros del compilador |
| 262 |
y del enlazador en el archivo de datos y la macro configure no |
| 263 |
comprueba si la librería funciona. Afortunadamente esto no ocurre muy |
| 264 |
a menudo. |
| 265 |
</p> |
| 266 |
|
| 267 |
<p> |
| 268 |
Para crear el archivo configure, es necesario PKG_CHECK_MODULES, |
| 269 |
contenido en la librería <path>pkg.m4</path>. Se debe añadir dicho |
| 270 |
archivo a nuestro directorio m4. Si la dependencia pkg-config es |
| 271 |
obligatoria (dado que la macro configure ejecuta esta herramienta) no |
| 272 |
se puede tener la certeza de que nuestro archivo m4 sea el mismo que |
| 273 |
se encuentre en el sistema de los usuarios, así como tampoco de que no |
| 274 |
incluya otros errores, dado que puede ser anterior a la nuestra. |
| 275 |
</p> |
| 276 |
|
| 277 |
<p> |
| 278 |
<b>Comprobar siempre las librerías con las que se va a enlazar</b>, si |
| 279 |
se tienen como dependencias obligatorias. Generalmente las macros |
| 280 |
autoconf o los archivos de datos pkg-config definen los pre-requisitos |
| 281 |
de librerías que se necesitan enlazar con nuestra librería. Además, |
| 282 |
algunas funciones que se encuentran presentes en algunas otras |
| 283 |
librerías extras (como dlopen() en libdl en Linux y Mac OS X) pueden |
| 284 |
estar en la libc de otros sistemas (esta misma función se encuentra |
| 285 |
presente en la libc de FreeBSD). En estos casos, se necesita comprobar |
| 286 |
dónde se encuentra la función sin enlazar a nada por el momento o si |
| 287 |
se necesita usar una librería específica (para evitar enlazar a una |
| 288 |
libdl inexistente que fallará cuando no sea necesaria, por ejemplo). |
| 289 |
</p> |
| 290 |
|
| 291 |
<p> |
| 292 |
<b>Ser cuidadoso con las extensiones GNU</b>. Una de las cosas que |
| 293 |
hacen realmente difícil la portabilidad es el uso de funciones de |
| 294 |
extensión, proporcionadas por la libc de GNU, pero no por otras |
| 295 |
librerías C de otros sistemas como BSD o uClibc. Cuando se usan dichas |
| 296 |
funciones, ha de proporcionarse algún tipo de "reemplazo al vuelo", |
| 297 |
una función que proporcione la misma funcionalidad que la de la |
| 298 |
librería, probablemente sin el mismo rendimiento o seguridad, que |
| 299 |
pueda ser usado cuando la función de extensión no esté presente en la |
| 300 |
librería C del sistema. Estas funciones deben estar protegidas por un |
| 301 |
bloque #ifdef HAVE_función ... #endif, para que no se dupliquen cuando |
| 302 |
se encuentren ya presentes. Hay que asegurarse de que estas funciones |
| 303 |
no son exportadas por la librería a usuarios externos; deben ser |
| 304 |
declaradas dentro de una cabecera interna, para evitar romper otras |
| 305 |
librerías que estén haciendo trucos similares. |
| 306 |
</p> |
| 307 |
|
| 308 |
<p> |
| 309 |
<b>Evitar compilar código específico de un SO cuando no se |
| 310 |
necesite</b>. Cuando un programa soporta librerías específicas o un |
| 311 |
sistema operativo específico, no es raro tener archivos completos de |
| 312 |
código que son específicos para los mismos. Para evitar compilarlos |
| 313 |
cuando no se necesiten, se usa la macro AM_CONDITIONAL dentro de un |
| 314 |
archivo configure.ac. Esta macro automake (únicamente usable si se |
| 315 |
está usando automake para construir el proyecto) nos permite definir |
| 316 |
bloques if ... endif dentro de un archivo Makefile.am, dentro del cual |
| 317 |
se pueden definir variables especiales. Se puede, por ejemplo, añadir |
| 318 |
una variable "platformsrcs" en la que podemos ajustar el archivo de |
| 319 |
código fuente correcto para el tipo de plataforma para la que estamos |
| 320 |
compilando, para usarla después en una variable _SOURCES. |
| 321 |
</p> |
| 322 |
|
| 323 |
<p> |
| 324 |
De cualquier modo, hay dos errores muy comunes que los desarrolladores |
| 325 |
cometen cuando usan AM_CONDITIONAL. El primero es el uso de |
| 326 |
AM_CONDITIONAL en una rama que ya es condicional (por ejemplo, en el |
| 327 |
caso de un conmutador info o case), lo que conduce a que automake se |
| 328 |
queje de que un condicional se ha definido sólo condicionalmente |
| 329 |
(AM_CONDITIONAL debe ser llamado sólo con un alcance global, fuera de |
| 330 |
cada bloque if, por lo que debe definirse una variable que contenga el |
| 331 |
estado de las condiciones para después hacer todas las comprobaciones |
| 332 |
cuando se llame a AM_CONDITIONAL). El otro es que no se pueden cambiar |
| 333 |
las variables de los objetivos directamente, y deben definirse |
| 334 |
variables de "materia", cuyos resultados estén fuera del condicional, |
| 335 |
para añadir o eliminar objetivos o archivos de código fuente. |
| 336 |
</p> |
| 337 |
|
| 338 |
<p> |
| 339 |
Muchos proyectos, para evitar compilar el código por rutas específicas |
| 340 |
de código, añaden los archivos completos en condicionales del |
| 341 |
preprocesador #ifdef ... #endif. Mientras que esto suele funcionar, |
| 342 |
hace el código más feo y más propenso a errores, dado que una sola |
| 343 |
sentencia fuera del bloque condicional puede ser compilada donde no se |
| 344 |
necesita en el archivo de código fuente. También engaña a los usuarios |
| 345 |
a veces, dado que los archivos de código fuente parecen ser compilados |
| 346 |
en situaciones en las que no tienen ningún sentido. |
| 347 |
</p> |
| 348 |
|
| 349 |
<p> |
| 350 |
<b>Tratar de hacer lo mejor posible la búsqueda de sistemas operativos |
| 351 |
o plataformas hardware</b>. A veces se necesita buscar un sistema |
| 352 |
operativo o plataforma hardware específicos. La forma correcta de |
| 353 |
hacerlo depende de dónde en concreto se necesite saberlo. Si se |
| 354 |
necesita saberlo para habilitar comprobaciones especiales en |
| 355 |
configure, o si se necesitan añadir objetivos adicionales en los |
| 356 |
makefiles, se debe hacer la comprobación en configure.ac. Por otra |
| 357 |
parte, si debe saberse la diferencia en un archivo de código fuente, |
| 358 |
por ejemplo, para habilitar una función opcional con código en |
| 359 |
ensamblador, se debe confiar directamente en el |
| 360 |
compilador/preprocesador, por lo que se deben usar directivas #ifdef |
| 361 |
con las macros habilitadas por defecto en la plataforma de destino |
| 362 |
(por ejemplo __linux__, __i386__, _ARC_PPC, __sparc__, _FreeBSD_ y |
| 363 |
__APPLE__). |
| 364 |
</p> |
| 365 |
|
| 366 |
<p> |
| 367 |
<b>No ejecutar comandos en configure.ac</b>. Si se necesita comprobar |
| 368 |
el hardware o el sistema operativo en un configure.ac, se debe evitar |
| 369 |
el uso del comando uname, a pesar de que esta sea una de las formas |
| 370 |
más comunes de hacerlo. Actualmente es un error, dado que rompe la |
| 371 |
compilación cruzada. Autotools soporta compilación cruzada de una |
| 372 |
máquina a otra usando definiciones de anfitriones: cadenas de tipo |
| 373 |
"hardware-vendor-os" (actualmente, "hardware-vendor-os-libc" cuando se |
| 374 |
usa GNU libc), tales como i686-pc-linux-gnu y |
| 375 |
x86_64-unknown-freebsd5.4. CHOST es la definición del anfitrión del |
| 376 |
sistema para el que se está compilando el software, CBUILD es la |
| 377 |
definición del anfitrión del sistema en el que se está compilando; |
| 378 |
cuando CHOST y CBUILD difieren, estamos haciendo compilación cruzada. |
| 379 |
</p> |
| 380 |
|
| 381 |
<p> |
| 382 |
En los ejemplos anteriores, la primera definición del anfitrión hace |
| 383 |
referencia a un sistema con un procesador equivalente a un pentium2 (o |
| 384 |
posterior), ejecutando un núcleo Linux con una libc GNU (por lo |
| 385 |
general se refiere a un sistema GNU/Linux). El segundo se refiere a un |
| 386 |
sistema AMD64 con un sistema operativo FreeBSD 5.4. (Para un sistema |
| 387 |
GNU/kFreeBSD, que usa el núcleo FreeBSD y GNU libc, la definición del |
| 388 |
anfitrión es hw-unknown-freebsd-gnu, mientras que para un |
| 389 |
Gentoo/FreeBSD, usando el núcleo y libc FreeBSD, pero con el marco |
| 390 |
Gentoo, la definición del anfitrión es hw-gentoo-freebsd5.4). Usando |
| 391 |
las variables $host y $build en una macro configre.ac se pueden |
| 392 |
habilitar o deshabilitar características específicas basándose en el |
| 393 |
sistema operativo o la plataforma hardware en la que se está |
| 394 |
compilando o para la que se va a compilar. |
| 395 |
</p> |
| 396 |
|
| 397 |
<p> |
| 398 |
<b>No abusar de las dependencias "automágicas"</b>. Una de las |
| 399 |
características más útiles de autotools es la comprobación automática |
| 400 |
de la presencia de librerías, que se usan a menudo para añadir soporte |
| 401 |
para dependencias adicionales y similares. Sin embargo, abusar de esta |
| 402 |
característica hace que la construcción de un paquete sea un poco |
| 403 |
problemática. Mientras que se trata de algo muy útil para quienes la |
| 404 |
usan por primera vez, y para casi todos los proyectos que tengan |
| 405 |
dependencias complejas (como con programas multimedia tales como xine |
| 406 |
y VLC) usan una capa basada en los módulos que les permite evitar |
| 407 |
rupturas, las dependencias "automágicas" son un buen dolor de cabeza |
| 408 |
para los empaquetadores, especialmente para aquellos trabajando en |
| 409 |
distribuciones basadas en código fuente como Gentoo y capas de tipo |
| 410 |
ports. Cuando se construye algo con dependencias automágicas se |
| 411 |
habilitan funciones soportadas por las librerías que se encuentran en |
| 412 |
el sistema donde se ejecuta la macro configure. Lo cual significa que |
| 413 |
los binarios obtenidos pueden no funcionar en un sistema que comparta |
| 414 |
los mismos paquetes básicos pero que no disponga de una de las |
| 415 |
librerías adicionales, por ejemplo. Además, no pueden determinarse las |
| 416 |
dependencias exactas de un paquete, dado que algunas pueden ser |
| 417 |
opcionales y no construidas cuando las librerías no se encuentran |
| 418 |
presentes. |
| 419 |
</p> |
| 420 |
|
| 421 |
<p> |
| 422 |
Para evitar esto, autoconf nos permite añadir las opciones |
| 423 |
--enable/--disable y --with/--without a las macros configure. Con |
| 424 |
dichas opciones se puede habilitar o deshabilitar convincentemente una |
| 425 |
opción específica (como el soporte para una librería adicional o de |
| 426 |
una característica específica), y dejar tomar por defecto los valores |
| 427 |
de las comprobaciones automáticas. |
| 428 |
</p> |
| 429 |
|
| 430 |
<p> |
| 431 |
Lamentablemente, muchos desarrolladores no entienden bien el |
| 432 |
significado de los dos parámetros de las funciones usadas para añadir |
| 433 |
estas opciones (AC_ARG_ENABLE y AC_ARG_WITH). Representan el código a |
| 434 |
ejecutar cuando se les pasa un parámetro o cuando no se les pasa |
| 435 |
otro. Muchos desarrolladores piensan equivocadamente que ambos |
| 436 |
parámetros definen el código a ejecutar cuando la característica está |
| 437 |
habilitada y deshabilitada. Mientras que esto funciona normalmente |
| 438 |
cuando se le pasa un parámetro sólo para cambiar el comportamiento por |
| 439 |
defecto, muchas distribuciones basadas en código fuente le pasan |
| 440 |
parámetros también para confirmar el comportamiento por defecto, lo |
| 441 |
que conduce a errores (características solicitadas explícitamente no |
| 442 |
presentes). Ser capaz de deshabilitar características opcionales si no |
| 443 |
añaden dependencias (pensemos en el soporte de audio OSS en Linux) es |
| 444 |
siempre una buena cosa para los usuarios, que pueden evitar construir |
| 445 |
cierta cantidad de código si no piensan usarlo y previene que los |
| 446 |
desarrolladores añadan sucios trucos para cachear si habilitan o |
| 447 |
deshabilitan una característica según los usuarios la soliciten. |
| 448 |
</p> |
| 449 |
|
| 450 |
<p> |
| 451 |
Mientras que las autotools fueron un gran problema tanto para |
| 452 |
desarrolladores como para mantenedores debido a que hay versiones |
| 453 |
diferentes incompatibles que no se llevan demasiado bien juntas |
| 454 |
(debido a que se instalan en los mismos sitios, con los mismos |
| 455 |
nombres) y que son usadas en diferentes combinaciones; el uso de |
| 456 |
autotools hace que los desarrolladores eviten usar todo tipo de juego |
| 457 |
sucio para compilar software. Si se miran los ebuild de portage en |
| 458 |
Gentoo, los pocos que no usan autotools son los más complejos, dado |
| 459 |
que deben comprobar variables en muchas configuraciones muy diferentes |
| 460 |
(podemos o no tener soporte NPTL; podemos estar bajo Linux, FreeBSD o |
| 461 |
Mac OS X; podemos estar usando GLIBC o cualquier ptra libc; y así), |
| 462 |
mientras que las autotools se ocupan de esto por sí mismas. También es |
| 463 |
cierto que muchos parches aplicados por sus mantenedores son para |
| 464 |
corregir macros defectuosas en el código fuente de orígen, pero esto |
| 465 |
es un pequqeño problema comparado con el caos que genera usar sistemas |
| 466 |
de construcción especiales que no funcionan en absoluto con pequeñas |
| 467 |
modificaciones del entorno. |
| 468 |
</p> |
| 469 |
|
| 470 |
<p> |
| 471 |
Las autotools pueden ser difíciles para los recién llegados, pero |
| 472 |
cuando se empiezan a usar a diario se encuentra que es mucho más fácil |
| 473 |
que tener que elaborar makefiles manualmente u otras extrañas |
| 474 |
herramientas de construcción como imake o qmake, o peor aún, macros de |
| 475 |
construcción tipo autotools que tratan de reconocer el sistema en el |
| 476 |
que se están construyendo. Autotools hace sencillo soportar nuevos |
| 477 |
sistemas operativos y nuevas plataformas de hardware, y evita a los |
| 478 |
mantenedores y portadores tener que aprender como construir un sistema |
| 479 |
para resolver adecuadamente la compilación. Escribiendo cuidadosamente |
| 480 |
una macro, los desarrolladores pueden soportar nuevas plataformas sin |
| 481 |
el más mínimo cambio. |
| 482 |
</p> |
| 483 |
</body> |
| 484 |
</section> |
| 485 |
</chapter> |
| 486 |
</guide> |
| 487 |
|
| 488 |
|
| 489 |
|
| 490 |
-- |
| 491 |
gentoo-commits@g.o mailing list |
Archives