Ésta es la versión G o o g l e guardada en el caché de la http://nexus.hispalinux.es/docs/misc/linuxprj/html/ obtenida el 10 Jul 2005 09:10:23 GMT.
La caché de G o o g l e es la instantánea de la página que tomamos cuando exploramos la Web en forma automática.
Es posible que la página haya cambiado desde entonces. Haga clic aquí para ver la página actual sin resaltar.
Esta página guardada en el caché puede hacer referencia a imágenes que ya no están disponibles. Haga clic aquí para obtener únicamente el texto guardado en el caché.
Para vincularse a esta página o para marcarla, utilice el siguiente url: http://www.google.com/search?q=cache:CQ291_2EtUkJ:nexus.hispalinux.es/docs/misc/linuxprj/html/+Creaci%C3%B3n+y+Administraci%C3%B3n+de+proyectos+Linux&hl=es


Google no tiene relación con los autores de esta página ni es responsable de su contenido.
Se han resaltado estos términos de búsqueda: creación administración proyectos linux 

next_inactive up previous


Creación y Administración de proyectos Linux.

Toni Moreno Giménez.

Abstract:

Este documento se encuentra enmarcado dentro del grupo de documentos que se generan dentro del proyecto Nexus. Por ese motivo es muy probable encontrarse ejemplos y nombres de ficheros o directorios correspondientes a paquetes de fuentes dentro del Proyecto Nexus, concretamente Gsound.


Contents

1 Herramientas y elementos administrativos.

Para escoger las herramientas adecuadas debemos tener en cuenta cual va a ser el resultado final del proyecto, En el caso de Gsound una de los requerimientos que hemos impuesto es que sea una libreria sencilla de usar para cualquiera con vagos conocimientos de programación en C, es decir no solo es necesario encontrar el conjunto de herramientas de desarrollo mas que mas se ajusten a los requerimientos, sino que es necesario encontrar algún medio de documentación eficiente, que simplifique la tarea del programador, la documentación de código ha sido una de las claves del éxito o fracaso de muchos proyectos software, sean libres o propietarios. El ejemplo más claro esta en Java, no solo por la cantidad de recursos de marketing que Sun Microsystems ha usado para lanzar este lenguaje de programación sino por la simplicidad que tienen los desarrolladores de encontrar documentación. Esta simplicidad es debida en gran parte al uso de ``javadoc'' una aplicación que automatiza la documentación de código.

Así pues es necesario encontrar las herramientas más adecuadas tanto para desarrollo, para documentación, administración y distribución.

1.1 Herramientas de Desarrollo.

Uno de los requerimientos que hemos impuesto es que sea multiplataforma, hoy en día la cantidad de sistemas diferentes es importante, y realizar una tarea así no es obvio. No solo por las sutiles diferencias que puedan haber entre distintos sistemas Unix como Linux , Solaris , Aix , HPUX , etc; por las inmensas diferencias con Windows y MacOS .sino mas bien por las diferentes herramientas de desarrollo que existen para cada una de las plataformas antes mencionadas.

Solo existe un modo viable de realizar este proyecto multiplataforma, y es usando las herramientas GNU de desarrollo, estas nos proporcionan unos scripts muy útiles de configuraciones , y de opciones de compilación nos permitirán concentrarnos mas en las opciones comunes a todo Unix, Para el caso de Windows existe Cygnus, un shell para windows que nos proporciona la posibilidad de compilar código y enlazarlo con las APIS de windows, este shell nos permite usar también las herramientas GNU.

1.1.1 Compilador y enlazado.

Para compilar se opta por el compilador gcc , de GNU , y la herramienta make.

El propósito de la utilidad make es determinar automáticamente qué piezas de un programa necesitan ser recompiladas, y lanzar las órdenes para recompilarlas. Este manual describe la implementación de make del proyecto GNU, que ha sido escrita por Richard Stallman y por Roland McGrath. Nuestros ejemplos muestran programas en C, que es lo más común, pero se puede emplear make con cualquier lenguaje de programación cuyo compilador pueda ejecutarse con una orden del shell. De hecho, make no está limitado a compilar programas. Se puede usar para describir cualquier tarea donde algunos ficheros deban ser actualizados automáticamente a partir de otros en cualquier momento en que éstos cambien. Para prepararnos a utilizar make, debemos escribir antes un fichero llamado el Makefile que describe las relaciones entre los ficheros de nuestro programa, y las órdenes necesarias para actualizar cada fichero. En un programa, normalmente el fichero ejecutable se actualiza a partir de los ficheros o módulos objeto, los cuales a su vez se construyen mediante la compilación de los ficheros con el código fuente. Una vez que exista un Makefile apropiado, cada vez que cambiemos algún fichero fuente, esta simple orden:

$>make 
basta y sobra para que se realicen todas las recompilaciones necesarias. El programa make emplea los datos del Makefile (y otros internos) y los tiempos de última modificación de los ficheros para decidir cuáles de ellos necesitan ser actualizados. Para cada uno de esos ficheros, lanza las órdenes que tiene grabadas en su base de datos.

1.1.2 Herramientas de soporte multiplataforma

Las herramientas son:

  1. Autoconf. Es una herramienta que produce shell scripts (configure) que automáticamente configura el código fuente para adaptarlo la mayoría de sistemas tipo UNIX. Estos shell scripts creados son independientes de autoconf. es decir los usuarios que compilen un paquete con el shell script configure no deben por que tener instalado autoconf. Al final . el resultado de ejecutar el script es un fichero de cabecera ``config.h'' con macros de preprocesador en C (#define) en función de las opciones multiplataforma que el desarrollador desee incorporar. (http://www.gnu.org/software/autoconf/)
  2. Automake. Genera los ficheros Makefile, necesarios y permite de forma sencilla reordenar y reestructurar los ficheros de código. (http://www.gnu.org/software/automake/automake.html)
  3. Libtool. Es una herramienta que facilita la creación de librerías para diferentes sistemas según las opciones de enlazado de estas. (http://www.gnu.org/software/libtool/libtool.html)
  4. DDD una interfaz gráfico del depurador de linea de comandos GNU gdb (http://www.gnu.org/software/ddd/)
  5. memprof es una herramienta que nos permite el chequeo de la memoria, para detectar zonas de memoria que no han sido liberadas o localizadas adecuadamente, puesto que el tratamiento continuo de buffers de audio y procesamiento de estos es abundante, nos será muy útil debido a la cantidad de trabajo con memoria dinámica que requiere la libreria.
  6. gprof: Es una herramienta que genera el perfil de ejecución de un determinado programa. Entre otras posibilidades muestra el tiempo de ejecución de cada una de las rutinas del sistema
  7. indent: herramienta GNU de indentación de código.

1.2 Herramientas de comunicación.

La libreria se esta desarrollando en el contexto del desarrollo distribuido, para ser mas exacto de código libre con Licencia Publica GNU, eso implica que diferentes personas podrían trabajar sobre el mismo proyecto en desde diferentes ubicaciones y sin contacto físico directo. Para poder coordinar un trabajo de este estilo es necesario algún medio de desarrollo distribuido, CVS y algún medio de comunicación entre desarrolladores (listas de correo y canal de IRC).

1.2.1 Concurrent Version System:

CVS es un sistema de control de versiones, que nos permitirá mantener las versiones antiguas de nuestros archivos (normalmente código fuente), manteniendo un log acerca de quien, y cuando ha introducido algún cambio, etc., del mismo modo que otros sistemas similares como RCS o el estándar de Unix SCCS. A diferencia de un sistema mas simple simple, CVS no trabaja sobre un archivo o un directorio a la vez sino que trabaja sobre una o varias colecciones de directorios organizados de manera jerárquica que consisten en archivos con control de versión. CVS además ayuda a administrar versiones y actualizaciones de los ficheros y a controlar la edición concurrente de los ficheros entre múltiples autores . CVS permite controlar operaciones sobre los ficheros y trabajar de modo local o remoto sobre una redes de área local o de área extensa.

En el caso de nuestra libreria el servidor CVS es accesible a través de Internet, y se encuentra ubicado en la dirección IP 147.83.50.103, para obtener más información acerca del desarrollo distribuido con CVS ver el apéndice INTRODUCCIÓN AL CVS.

1.2.2 Listas de Correo y Canal.

El sistema CVS tiene muchas virtudes, pero en ningún momento permite es administrar un proyecto, la administración, acerca de qué ,quién y cómo debe realizarse, independientemente de control de versiones y de desarrollo distribuido CVS, por ello se hace necesario un medio de comunicación entre desarrolladores. Seria conveniente un sistema on-line y otro off-line.

1.3 Herramientas de Documentación.

Este proyecto tiene 2 tipos de documentación necesario. por un lado las especificaciones de diseño y guia de desarrollo ( i.e. este documento),para aquellos programadores que deseen modificar, mejorar o añadir funcionalidades a la libreria. Por otro lado es necesaria la creacion de 1 documentos directamente relacionados con el código fuentes, es el manual de referencia para desarrolladores que necesiten programar su aplicación y hagan uso se gsound como un recurso valido.

Estos 2 documentos además deberían ser fácilmente accesibles a los usuarios a los que van dirigidos, atendiendo los actuales estándares de documentación , es necesario al menos tener accesible los documentos a través de Internet en formato HTML (hipertext Markup Language), y en algún otro que facilite la impresión en papel. por ejemplo en formato PDF (Portable Document format).

Hasta la fecha toda la documentación ha estado realizándose mediante un procesador de texto en formato TEX que permite creación de documentos en formato dvi (device independent) y ps(postscript) así como pdf. Esta herramienta gráfica (LYX) que no es mas que un interfaz gráfico de LATEX ,es muy útil para el caso de Las especificaciones de diseño, no así para documentar código. Así pues necesitamos algún otro medio de documentación para realizar el manual de referencia y la guia de desarrollo.

Después de revisar diferentes opciones se han llegado a 4 posibles soluciones:

  1. Texinfo: las propias herramientas de documentación GNU de proyectos. Esta utilidad obliga al desarrollador a escribir en ficheros de documentación separados de las fuentes, la separación es un factor limitador las reescrituras de código y/o ampliaciones obligan a reeditar un fichero separado un método algo engorroso cuando se trata de un proyecto grande con múltiples ficheros de código y muy probablemente de documentación.
  2. KDoc (basado en Docbook?)
  3. Gtk-doc(http://www.gtk.org/)
  4. Doxygen. (http://www.stack.nl/ dimitri/doxygen/)Es una herramienta al estilo javadoc. Que documenta cualquier código fuente en C,C++, y IDL directamente desde los comentarios que el desarrollador va escribiendo a medida que escribe el código, sin duda alguna este es el mejor método de tener siempre una documentación actualizada si tener que buscar y editar aquel fichero en el cual estaba comentado esta función o estructura, es tremendamente flexible, puesto que admite etiquetas TEX, y busca funciones y estructuras de datos aun a falta de comentarios explícitamente escritos por el desarrollador. Para el caso de herramientas de desarrollo es muy bueno puesto que documenta en formato, rtf, HTML, TEX ( que permite con LATEX generar documentos dvi,ps y pdf), y paginas de manual (man) Unix .
Una vez enumeradas las herramientas más comunes de documentación del código de proyectos, se decide usar doxygen, debido a la comodidad en la generación de documentos directamente desde los archivos de código fuente. Se ha descartado KDoc por estar exclusivamente diseñado para proyectos escritos en C++, y Gtk-doc por ser una versión muy temprana (0.2) con evidentes carencias.

1.3.1 Otras utilidades.

Para la creacion de imágenes para la documentación o las paginas web:

  1. Gimp: Para la creacion de logos e imágenes de diseño (www.gimp.org)
  2. Xfig: Para los diagramas de bloques(www.xfig.org)
  3. ImageMagic: convert,display, animate, montage, nogrify combine, son un conjunto de herramientas de manipulación de imágenes. (www.imagemagick.org)
Conversión TEX a HTML : latex2html (http://saftsack.fs.uni-bayreuth.de/ latex2ht/)

1.3.2 administración y distribución.

Una vez decididas las herramientas de documentación, vamos a especificar el lugar donde emplazarlas.

sea distdir el directorio base en el cual nos disponemos a emplazar el proyecto, la distribución de los diferentes archivos es la siguiente

distdir/
el directorio base, debe contener los archivos de administración de todo el proyecto. son aquellos automáticamente generados por las herramientas, libtool,autoconf, y configure. Los archivos que han debido ser generados manualmente son:
distdir/src
debe ser la base del código fuente, en este directorio y subsiguientes en el árbol de directorios se deben emplazar los archivos de código a compilar, además de algunos de configuración del Automake (Makefile.am).
distdir/examples
en este directorio se ubicará el código fuente de diversos ejemplos, de uso de la libreria, así como sus respectivos Makefile, para poder compilarlos y probarlos.
distdir/docs
es el directorio base de la documentación del proyecto, la cual se subdivide en:

distdir/docs/design
aquí se ubican los ficheros de creacion y distribución de documentación referente a diseño , tal como se ha especificado con anterioridad. (mediante LYX y LATEX).
El nombre de los ficheros que generaremos debe ser <proyecto>_design.lyx mediante el que generamos el <proyecto>_design.tex y a través de las herramientas, latex, latex2html,y pdflatex ( en caso de desear un archivo pdf con soporte de hiper enlaces)1.
En este caso los documentos mínimos que deben estar ubicados en dicha localización son gsound_design.lyx y gsound_design.tex.
distdir/docs/refman
en este directorio la utilidad doxygen, debe generar la documentación extraída del código fuente.
distdir/{intl,po}
Soporte de internacionalización, mediante la herramienta GNU gettext. (Solo se compila en con la opción -with-include-gettext del configure, y solo es útil en caso de que nuestro sistema no disponga de las opciones avanzadas del gettext de GNU), para mas detalles del funcionamiento de gettext, leer el archivo ABOUT-NLS. En intl se encuentra el código fuente de la libreria libintl. y en el directorio po los archivos de configuración del soporte de internacionalización.

1.4 Herramientas de distribución.

La distribución del software desarrollado se realizara mediante diferentes tipos de paquetes de distribución.

Para la distribución podemos encontrar algunas herramientas http://rpm.redhat.com/software.html que nos facilitaran la creacion de estos paquetes.

1.5 Reglas de Make, para automatización de documentación y distribución

La herramienta GNU Automake automáticamente genera objetivos estándares de compilación documentación y empaquetado de las fuentes, para la herramienta make entre otras destacamos las siguientes como por ejemplo;

make [all]:
construye los binarios
make info:
formatea los archivos de documentación de la utilidad Texinfo
make dist:
construye el paquete tar.gz con los fuentes y archivos de soporte al paquete
make distcheck:
 
make install:
instala los binarios,, documentación, scripts , tal como lo haya previsto el administrador de las fuentes etc etc. en el sistema directamente de la compilación, previa con make o make all.
make install-strip:
lo mismo que el anterior pero elimina los símbolos que mantienen los binarios con la opción -g para el depurado. de este modo se se reduce el tamaño de las fuentes.
pero no soporta herramientas externas como Doxygen , pdflatex o rpm , alien , dpkg que forman parte de las herramientas que necesitamos para cumplir las especificaciones de documentación y distribución de tal modo que se van a añadir en el Makefile unas reglas estándares para construir nuestros paquetes extra de distribución así como la documentación, tal como se ha especificado anteriormente. Una limitación importante es observar que estas reglas solo pueden ser usadas por el administrador del proyecto, en cuanto a documentación se refiere , solo se distribuirán , las documentaciones en formato pdf y html no así las fuentes TEX o LYX. de tal modo que las siguientes reglas de Make aparecerán para todos los usuarios que adquieran los paquetes tar.gz o tar.bz2 pero no podrán usarlas puesto que no dispondrán de los archivos fuente.

Las reglas especificas de documentación y distribución, son:

1.5.1 Documentación

make docdesign:
genera los archivos de documentación de diseño en formato pdf y html
make docrefman:
genera los manuales de referencia en formato pdf ,html, man , rtf.
make alldocs:
genera toda la documentación.

1.5.2 Paquetes de Distribución

make sourcedist:
genera los paquetes de distribución en formatos tar.gz tar.bz2
make rpm:
genera los paquetes de distribución en formato RPM. Son 3 :

make deb:
genera los paquetes de distribución en formato DEB en este caso solo son 2

1.5.3 Ftp:

1.5.4 Test:

Son las reglas de construcción de los diferentes binarios destinados a testear el correcto funcionamiento de la libreria.

make test:
compila los ejemplos según las reglas del Makefile.test
make cleantest:
elimina los binarios y archivos intermedios resultado de compilar los ejemplos
Otros.
 
make winlibs:
construye las librerías dinámicas (dll) para windows ( bajo entorno Cigwin)

1.6 Portabilidad a otras plataformas.

Para asegurar la portabilidad a otros sistemas Unix , debemos asegurar primero que todo código estará escrito en ANSI C , a pesar de que algunas rutinas se optimicen para iX86. Teniendo en cuenta que estamos usando las herramientas de compilación GNU serán mínimos los cambios que se tengan que hacer para poder compilar la libreria en sistemas como Irix o Solaris, puesto que las herramientas GNU están especialmente construidas para desarrollar software portables. El caso mas difícil lo tenemos en Windows. Para poder portal el código a windows existe,una utilidad que permite usar herramientas POSIX sobre sistemas windows. Esta herramienta Cygwin (http://www.cygwin.com/) emula un shell Unix y un sistema de archivos Unix, con las principales aplicaciones que se puedan usaren Unix, interpretes como Perl , aplicaciones como sed awk o grep. de tal modo que permiten el uso de las herramientas GNU de desarrollo.

1.6.1 En sistemas Unix.

Como ya se ha comentado , las herramientas GNU automatizan el proceso de compilación sobre diferentes plataformas, y en caso de otros Unix no será demasiado complicado, En la medida que Libtool automatizando la creacion para diferentes sistemas Unix, esta libreria podrá ser portada a dichos sistemas. En la documentación de Libtool se especifica una lista de plataformas en los que dicha herramienta funciona, concretamente en 88 plataformas distintas se ha comprobado con éxito el funcionamiento. Solo en 9 de ellas por características propias de los sistemas no aceptan librerías dinámicas, aunque si estáticas. Todo ello automatizado por Libtool

1.6.2 Windows ( Cygwin y Mingw32)

Como ya se ha introducido existen unas herramientas que emulan un sistema POSIX , funcionando sobre win32 , mediante las cuales podremos ejecutar los scripts de configuración , generados por autoconf, Automake y libtool.

Una de las exigencias del proyecto, ha sido hacer nuestro software lo mas rápido posible , si no fuera así no haríamos ningún comentario acerca del modo en que estas herramientas de emulación funcionan, puesto que no es el caso, se ha estudiado con un poco de detenimiento el funcionamiento de Cygwin.

En el entorno de Cygwin existen 2 modos de compilar las fuentes de cualquier aplicación Unix, el primer modo es simplemente aprovechar la emulación del entorno. En tal caso una aplicación, cualquiera sera enlazada con las librerías del sistema windows, y con una libreria especial del entorno Cygwin que realiza la emulación POSIX. (Cygwin1.dll).

Pero existe un modo de indicarle al compilador que en lugar de usar esa emulación use unas librerías de C que directamente hacen llamadas al kernel32 de windows, sin emulación intermedia m el el mno-cygwin-howto http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html describe con más detalle el funcionamiento, que a continuación se va a introducir. A este modo de construir aplicaciones se les denomina ``Mingw32 compliants''.

Para construir aplicaciones en modo Mingw32 debemos simplemente indicar al compilador la opción -mno-cygwin.

En nuestro caso , el problema va un poco más lejos, puesto que no deseamos realizar una aplicación simple, si no que deseamos construir librerías, tanto estáticas como dinámicas, y para ello, hemos confiado en libtool.

Libtool permite la construcción de DLL's en nuestro entorno Cygwin, de forma automática, pero aunque los ficheros objeto sean Mingw32 compliant, la construcción de la dll que usa libtool enlaza directamente con cygwin1.dll por lo que nuestra libreria final , no es Mingw32 compliant. Para arreglar este problema evitaremos usar libtool, para la construcción de nuestras librerías dll y lib, en su lugar usaremos el mismo script que otras librerías como Glib, Gtk, o el propio Gimp usan. (build-dll), que usa herramientas de Cygwin y de Microsoft para construir las librerías dll y lib. en el [#!10!#, autobook] se especifican más detalles acerca de la construcción de dll's en entornos Cygwin (no Mingw32), que pueden ser usadas directamente en cualquier entorno de desarrollo para win32, se han probado con éxito VisualC++.

2 Creacion del esqueleto del proyecto,Administración.

2.1 Archivos de configuración de Automake, autoconf, libtool, distribución , documentación y generación de librerías para win32

Para crear el esqueleto del proyecto, necesitamos las autotools tal como se ha comentado previamente, en concreto autoconf Automake y libtool. Estas nos crean algunos ficheros de configuración, extra que no es necesario mantener. Los ficheros estrictamente necesarios para que las herramientas autotools funcionen están marcados en negrita.

De este modo autoconf necesita de entrada el fichero configure.in y config.h.in , Automake el fichero Makefile.am2. Para añadir soporte al make de creacion de paquetes de distribución y de creación de documentación se deben añadir las reglas, oportunas en los Makefile.am.

Makefile.am

Configure.in

acconfig.h

Puesto que se trata de una libreria facilitaremos un script de configuración para los desarrolladores que procesaremos con la herramienta autoconf para substituir algunas variables dependientes de la versión ( especificada en configure.in)

gsound-config.in3

gsound.m4

El script configure generará automáticamente el script gsound-config, y la macro AM_PATH_GSOUND() para añadir al configure.in de otras aplicaciones que requieran el uso de gsound.

Necesitamos además los ficheros de configuración extra, para facilitar el empaquetado en formatos RPM y de ese modo la distribución, del mismo modo que el anterior se debe procesar con autoconf para generar un fichero spec dependiente de la versión.

gsound.spec.in4
Nos falta el fichero de configuración de la herramienta de documentación Doxygen.

Doxyfile.
Debido a los errores detectados en la compilación en el entorno Cygwin, debemos incluir en el esqueleto el script de creacion de librerías estáticas y dinámicas para win32. y un archivo de documentación acerca del entorno Cygwin para el cual esta preparado el paquete.

build-dll5

README.win32

Antes de ejecutar las herramientas el paquete de fuentes debe contener los siguientes archivos. No son procesados por ninguna herramienta son solo

NEWS
Es un resumen de los cambios visibles para el usuario del último paquete con respecto al anterior. El formato no es estricto pero los cambios de la versión más reciente deben aparecer al principio del fichero.
README
El primer lugar que un usuario mirará para tener una visión acerca del propósito del paquete y tal vez instrucciones de instalación
AUTHORS
Fichero en el cual se especifican detalles acerca del autor. curiosidades y cualquier comentario que el autor del proyecto desee dar.
ChangeLog
Fichero que recoge los cambios que se van sucediendo a lo largo del proyecto, el formato de este fichero según se especifica en el GNU coding standars http://www.gnu.org/prep/standards.html. es bastante estricto

2.2 Creando el árbol de directorios .

En cada uno de los subdirectorios que siguen al directorio base del paquete de fuentes, debe contener un Makefile.am con la sintaxis adecuada que sera procesado automáticamente por Automake. para crear los Makefile finales.

Los Directorios creados tienen la siguiente finalidad:

src
es el directorio principal del cual cuelgan todos los ficheros de código fuente.
examples
contendrá ejemplos de codificación con Gsound, no solo para desarrolladores si no para poder probar los diferentes cambios que se vayan introduciendo
docs
es el directorio en el cual se ubicarán los ficheros de documentación.
build
este es un directorio extra con utilidades, ya sean scripts o binarios que ayudaran a la creación de la libreria.
Este es el árbol creado6.

.

|- build

|- docs

|- examples

`- src

    |- audio

    |   |- agen

    |   `- aproc

    |- cda

    |- common

    |- data

    |- db

    |- dev

    |- includes

    |- midi

    |- net

    |- player

    `- sff

 

2.3 Creando el soporte para Automake y autoconf,libtool y gettext.

Esta es la secuencia de comandos que acaban de configurar el paquete de fuentes, siempre y cuando la sintaxis de los archivos hasta ahora mencionados sea la correcta. En adelante supondré que los archivos de configuración están correctamente editados.

$ aclocal 
(Es necesario tener todas las macros de configure.in en /usr/share/aclocal o invocar este comando con la opción -I<directorio_adicional_de_macros_m4>)

$ autoconf

$ autoheader

$ (comandos de soporte para libtool)7

$ gettextize -copy -force && touch po/Changelog po/es.po

Aparece el siguiente mensaje: (You should update your own `aclocal.m4' by adding the necessary macro packages gettext.m4, lcmessage.m4 and progtest.m4 from the directory `/usr/share/aclocal')

Se debe añadir los lenguajes que se hayan creado mediante la creacion de ficheros po/*.po en la variable ALL_LINGUAS del configure.in ( en nuestro caso ALL_LINGUAS=''es'' )

$ automake -add-missing

2.4 Añadiendo soporte de librerías dinámicas con Libtool.

2.4.1 Introducción a las librerías dinámicas.

Aveces, puede ser confuso hablar de librerías dinámicas , teniendo en cuenta que estas hacen referencia a 2 conceptos distintos.

  1. Compilación y enlazado de un programa, con una libreria compartida, que es resuelta en tiempo de ejecución, por el enlazador dinámico, en este proceso, el enlazado dinámico es transparente a la aplicación (ld).
  2. la aplicación llama a funciones como dlopen, que lee módulos arbitrarios, especificados por el usuario de la aplicaciones en tiempo de ejecución.
Para evitar confusiones a las primeras las llamaremos librerías dinámicas, y a las segundas módulos cargables o pluggins.

2.4.2 Generación del soporte de Libtool.

Una vez generado el paquete de código y scripts (configure.in,Makefile.am) junto con la estructura de ficheros y directorios . Se deben añadir unos scripts que proporcionan las opciones necesarias de compilación de librerías, mediante la herramienta libtool.

Vamos a entrar un poco más en detalle en este apartado , puesto que debemos conocer muy bien las opciones que permite libtool. Nuestra meta al final sera la creación de librerías , tanto estáticas como dinámicas, y además generar librerías dinámicas que funcionen como módulos cargables.

Lo primero es dar soporte al paquete para la creación de librerías, esto se realiza mediante el script ``libtoolize''

$ libtoolize  -copy -force

Esto nos copia los scripts ltmain.sh y ltconfig

Se ejecuta el ltconfig

$ ltconfig -[opciones]

( -enable-dlopen -enable-win32-dll ) ltmain.sh

crea el script libtool que se encargara de administrar toda la compilación y enlazado en la libreria.

Y se añade la entrada AM_PROG_LIBTOOL al configure.in.

Ahora ya podemos añadir las opciones pertinentes de compilación de librerías en los archivos Makefile.am8 ( ).

Para crear una libreria llamada ``milibreria'' y sus correspondientes librerías compartidas e instalarlas en libdir debemos escribir:

lib_LTLIBRARIES = libmilibreria.la

libmilibreria_la_SOURCES = miarchivo1.c miarchivo2.c ....etc

libhello_la_LDFLAGS = -version-info 3:12:1

En nuestro paquete de fuentes podemos indicar a libtool que queremos enlazar una libreria dinánmica o un módulo cargable solo especificando en el campo LDFLAGS las siguientes opciones:


LDFLAGS modo de enlazado
-module modulo cargable
-export-dynamic libreria dinámica


Esto es suficiente para instalar las librerías libmilibreria.{a,so,la} en el directorio libdir por defecto ( $prefix/lib) pero no crea los archivos de cabecera necesarios para poder desarrollar aplicaciones con estas librerías. para ello es necesario incluir las siguientes:

include_HEADERS = miinclude.h
NOTA: por defecto milibreria se construye dinámicamente independientemente de que esta pueda ser estática o no.

Index

Aix
1.1
animate
1.3.1
Autoconf
1.1.2
Automake
1.1.2
awk
1.6
Cignus
1.1
Cigwin
1.6
combine
1.3.1
configure
1.1.2
convert
1.3.1
DDD
1.1.2
DEB
1.4
display
1.3.1
Doxygen
1.3
dpkg
1.4
dvi
1.3
gdb
1.1.2
Gimp
1.3.1
GNU
1.1
grep
1.6
gz
1.4
h
1.1.2
HTML
1.3 | 1.3.1
ImageMagic
1.3.1
javadoc
1.3
KDoc
1.3
Libtool
1.1.2
Mac
1.1
make
1.1.1
Makefile
1.1.2
memprof
1.1.2
montage
1.3.1
nogrify
1.3.1
pdf
1.3
POSIX
1.6
ps
1.3
rpm
1.4 | 1.4
rtf
1.3
scripts
1.1
Solaris
1.1
TeX
1.3
TGZ
1.4
UX
1.1
Windows
1.1
Xfig
1.3.1

About this document ...

Creación y Administración de proyectos Linux.

This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.50)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 0 -html_version 4.0,latin1 -image_type png -dir ./html -mkdir -show_section_numbers proyectolinux.tex

The translation was initiated by Toni Moreno Giménez on 2002-02-26


Footnotes

... enlaces)1
En las versiones de pdflatex se han detectado algunos problemas en la inserción de imágenes con formato eps, de tal modo que es posible que que la generación del documento pdf se realice mediante el comando dvipdf en lugar de pdflatex, esto nos
... Makefile.am2
Para mas información acerca de la sintaxis de estos ficheros ver la documentación. xxxx
...]gsound-config.in3
este script es cada vez más típico de las distribuciones de soft de Linux, muy útil para incluir en makefile. Nos da las opciones de compilación , con gcc. ejecutado con el argumento -cflags nos devuelve por salida estándar la ubicación de los ficheros de cabecera de la libreria y con el argumento -libs devuelve por salida estándar la ubicación de los binarios
...]gsound.spec.in4
Para saber mas acerca de la sintaxis de este fichero en el RPM-howto .http://www.insflug.org/COMOs/RPM-Como/RPM-Como-6.html
...]build-dll5
Este script se puede encontrar en los paquetes de software glib-*.tar.gz gtk+*.tar.gz y gimp-*.tar.gz , que han sido portados con éxito a win32
... creado6
El contenido de cada directorio que cuelga del subdirectorio src y la justificación de esta estructura se detalla en el capítulos subsiguientes.
...\$ (comandos de soporte para libtool)7
Debido a la importancias de estos comandos, se explican con detalle en el siguiente apartado
... Makefile.am8
para mas información de las opciones ver info libtool -using automake- y info libtool Building a Shared Library

next_inactive up previous
Toni Moreno Giménez 2002-02-26