É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 |
|
|
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.
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.
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.
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.
Las herramientas son:
- 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/)
- 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)
- 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)
- DDD una interfaz gráfico del depurador de linea de comandos
GNU gdb (http://www.gnu.org/software/ddd/)
- 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.
- 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
- indent: herramienta GNU de indentación de código.
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).
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.
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.
- Off-line: Gsound Actualmente se encuentra enmarcado dentro del Proyecto Nexus http://tquevedo.hispalinux.es/nexus
, que dispone de 2 listas de correo para comunicación entre desarrolladores,
y entre desarrolladores y usuarios. Este es el medio off-line más
cómodo de mantener el contacto y el control sobre el desarrollo distribuido.
- gnu-nexus-devel@listas.hispalinux.es
- gnu-nexus-misc@listas.hispalinux.es
A estas listas se puede uno subscribir directamente desde la pagina
web del proyecto nexus.
- On-line: También disponemos de un medio on-line de comunicación, un
canal de IRC registrado en el irc-hispano. el canal es #nexus-project.
En el nos reunimos periódicamente los desarrolladores para acelerar
algunas discusiones que requieren la intervención de varios desarrolladores
y que por las listas de correo puede ser algo lento
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).
- Especificaciones de diseño. Es necesario concretar
al máximo todo lo que pueda afectar al futuro desarrollo de la libreria
de tal modo que el desarrollo sea lo mas fluido posible, aun así se
esperan muchas modificaciones ocasionadas simplemente por el desconocimiento
de ciertos temas , lo que va a obligar a reespecificar ciertas partes
de este documento. asimismo debe constituir una guia de desarrollo,para
aquellos desarrolladores que estén interesados en aportar su experiencia
al proyecto y de ese modo poder mejorarlo , en este aspecto es necesario
entrar con un poco de detalle en las estructuras de datos usadas y
las funciones, así como las consideraciones de diseño que han afectado
directamente a la elección de dichas estructuras y datos acerca de
mejoras, bugs, ampliaciones, comentarios , etc.
- manual de referencia. Debe ser una guía sencilla en
la que se enumeren los objetos y métodos asociados a estos objetos,
con una breve explicación del uso , y algunos ejemplos.
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:
- 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.
- KDoc (basado en Docbook?)
- Gtk-doc(http://www.gtk.org/)
- 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.
Para la creacion de imágenes para la documentación o las paginas web:
- Gimp: Para la creacion de logos e imágenes de diseño
(www.gimp.org)
- Xfig: Para los diagramas de bloques(www.xfig.org)
- 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/)
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.
La distribución del software desarrollado se realizara mediante diferentes
tipos de paquetes de distribución.
- [tar.gz]empaquetado típico del desarrollo basado en herramientas
GNU.
- [RPM:](Red Hat Package Manager) sistema de distribución de paquetes
de software, de todas las distribuciones de Linux basadas en Red Hat
- [DEB:]Sistema de distribución de paquetes de software
de las distribuciones de Linux basadas en Debian.
- [TGZ:]Es el sistema de empaquetado típico de las distribuciones
basadas en Slackware.
Para la distribución podemos encontrar algunas herramientas http://rpm.redhat.com/software.html
que nos facilitaran la creacion de estos paquetes.
- [rpm]es la aplicación de administración de paquetes RPM.
a su vez es el constructor de los paquetes RPMwww.rpm.org
- [dpkg]es la aplicación de administración de paquetes
DEB (dpkg-devel+debhelper)
- [rpmbuilder]un interfaz para crear ficheros de configuración. (spec)
para la creación de paquetes RPM.http://www.klabs.net/rpmbuilder/
- [alien:]es un conversor de formatos de paquetes de distribución.http://kitenet.net/programs/alien/
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:
- 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.
- 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 :
- [paquete.iX86.rpm]que contendrá las librerías compartidas.
- [paquete-devel.iX86.rpm]que contendrá además las librerías estáticas
, archivos de cabecera, y documentación para desarrolladores.
- [paquete.src.rpm]contiene los archivos con las fuentes. idénticamente
que tar.gz solo que en formato rpm. ( se recompilan las fuentes con
la opción -rebuilt de rpm)
- make deb:
- genera los paquetes de distribución en formato DEB en
este caso solo son 2
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)
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.
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
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++.
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
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
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
- el comando aclocal simplemente añade el fichero aclocal.m4
al paquete de código, contiene, las macros m4 que pueden ser añadidas
al script ./configure mediante el programa autoconf
y que deben estar en algún lugar de la maquina local (usualmente en
/usr/share/aclocal ) , estas macros suelen venir con los paquetes
de desarrollo de algunas librerías, por ejemplo la macro que proporciona
el paquete gtk+-devel , gtk.m4 permite que el configure.in
podamos incluir la macro AM_PATH_GTK( , , ) que a su salida exporta
las variables GTK_CFLAGS u GTK_LIBS, para incluir a la variable
CFLAGS y LIBS. de manera automática. De este modo autoconf automáticamente
incluye la macro, en ./configure.
- Autoconf genera el script ./configure a partir del configure.in generado
anteriormente y del aclocal.m4.
- En comando autoheader procesa el fichero acconfig.h
, para producir config.h.in , que más tarde usara el script configure
para crear el fichero de cabecera dependiente de la maquina en la
cual se vaya a realizar el proceso de compilación y enlazado de la
libreria.
El fichero acconfig.h debe eliminar la definición de todas
entradas de definiciones hechas en configure.in con la macro AC_DEFINE(definición),
de tal modo que debe contener una colección de
-
- #undef definicion
- El comando Libtoolize se explica con más detalle en el siguiente
apartado. añade soporte para la creacion de librerías dinámicas.
- El comando gettextize añade soporte de Internacionalización,
para el caso de la nuestra libreria sera útil usado para dar soporte
de internacionalización al los mensajes de log. Es necesario que en
el Configure.in se haya introducido la macro ALL_LINGUAS=''locale_id''
, AM_GNU_GETTEXT, donde locale_id, corresponde a los identificadores
de idioma, español=es, ingles=en alemán=de etc. Por razones que no
vienen al caso , es necesario incluir los ficheros po/Changelog y
todos los .po que se hayan incluido en ``locale_id'', es decir
que si incluimos ALL_LINGUAS=''es de fr'' , necesitaremos incluir
los ficheros es.po de.po fr.po.
Añade los siguientes ficheros
- ABOUT-NLS
- Este archivo contiene las instrucciones básicas del modo
de instalación y el uso de soporte de NLS (native Languaje Support)
a nuestra libreria.
- intl
- (directorio) se crea y se completa con los ficheros fuente originales
del directorio int/ de la distribucion GNU gettext (usualmente ubicada
en /usr/share/gettext)'.
- po
- (directorio) se crea para albergar eventualmente los archivos
de con las tablas de traducción, inicialmente solo contiene el archivo
`po/Makefile.in.in' .
- Automake genera los Makefile.in a partir de Todos los Makefile.am
que encuentre, y que en serán transformados en los Makefile finales
por el script ./configure.
Añade los archivos.
- install-sh
- script de instalación de ficheros. es usado en la regla
make install.
- mkinstalldirs
- script de construcción de directorios
- missing
- script de información sobre algún elemento de configuración
necesario , es usado internamente durante la instalación.
- INSTALL
- Instrucciones de instalación genéricas de todos los paquetes
administrados con Automake.
- COPYING
- La licencia de copia GNU GENERAL PUBLIC LICENSE
Aveces, puede ser confuso hablar de librerías dinámicas , teniendo
en cuenta que estas hacen referencia a 2 conceptos distintos.
- 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).
- 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.
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.
- 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
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
Toni Moreno Giménez
2002-02-26
