First •Prev •Next •Last •Go Back •Full Screen •Close •Quit

•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Estructura de la charla:
Introduccion.
Herramientas de desarrollo: linea de comando.
gnu make, autoconf, automake, configure, et.al.
cvs
diff y patch
i18n y l10n
ant (java)
Herramientas de desarrollo: visuales.
Glade, Anjuta, KDevelop y Kylix
Para Java: netbeans (www.netbeans.org), eclipse (www.eclipse.org),
Distribuyendo nuestra app.
Sourceforge http://www.sourceforge.net
Freshmeat http://freshmeat.net
Conclusiones.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Introducción
En esta charla vamos a intentar responder las siguientes preguntas:
¿Cómo puedo participar en proyectos de código abierto?
¿Cómo empiezo?
¿Qué herramientas tengo que conocer?
Lo más importante:
tener ganas y un poco de tiempo.
¿Por qué hacerlo?
Principamente diversón.
Pero además: es útil, ego y CV.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Algunos proyectos
Ya hay muchos proyectos interesantes.
• Kernel de Linux
• GTK / Gnome
• Gimp
• QT / KDE,
• Mozilla
• tu proyecto aquı́
Para poder aportar hay que saber algunas cosas:
• Programar: ya sea en C, C++, Java, Perl, php, etc.
• Conocer algunas herramientas básicas de desarrollo que hiremos disctuiendo aquı́.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Make
En programas grandes lleva tiempo compilar todo. Es más fácil dividir los
fuentes y compilar sólo lo que cambió. Para ello se utilizan archivos Makefile
y el programa make.
make maneja dependencias entre archivos.
tiene reglas para hacer distintas acciones: generar la aplicación, la documentación, instalar el programa, etc.
Tı́picamente para compilar un programa hacemos:
$ make all
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Make
Para entender cómo trabaja make hagamos un ejemplo sencillo. Tenemos dos
archivos en C, un header y el makefile: file1.c, file2.c, file1.h, makefile. Analizemos el siguiente makefile:
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
autoconf, et.al.
En proyectos grandes hay varios problemas que resolver:
• Muchas dependencias entre archivos: librerias, codigo, headers, etc.
• Requerimientos de librerias: X11, gtk, QT, etc.
• Soporte para diversas plataformas: Linux, Win32, *BSD, etc.
configure permite detectar todo esto automáticamente.
Tipicamente configure genera un Makefile y un config.h que toman en cuenta
todas las dependencias. Para compilar el programa:
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal-1.4... missing
checking for working autoconf... found
.
.
$ make
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
¿Cómo genero mi configure?
Por suerte no es muy difı́cil. Hay varios utilitarios para ayudar: autoconf,
automake, autoheader, etc.
negro: files obligatorios.
gris: opcionales
verde: ejecutables (scripts)
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
¿Cómo genero mi configure?
El procedimiento es el siguente:
1. Escribo configure.in y Makefile.am
2. Usando automake* genero Makefile.in
3. Usando autoheader* genero config.h.in (si uso config.h)
4. Usando autoconf* genero configure a partir de configure.in y
Makefile.in.
Para compilar mi programa sólo tengo que correr configure* y esto me genera
config.h y Makefile.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
1a. Escribo configure.in
AC_INIT(src/rio_format.c)
AM_INIT_AUTOMAKE(rio500, 0.8)
AM_CONFIG_HEADER(librio500/config.h)
...
AC_PROG_CC
AC_HEADER_STDC
...
AC_CHECK_HEADERS(fcntl.h sys/ioctl.h unistd.h)
AC_C_BIGENDIAN
...
AC_MSG_CHECKING(whether to link with ElectricFence)
AC_ARG_WITH(efence,
[ --with-efence
Link with ElectricFence
--without-efence Don’t Link with ElectricFence (default)],
[ case "$withval" in
yes)
...
*)
...
])
...
AC_OUTPUT(Makefile src/Makefile librio500/Makefile ... docs/Makefile)
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Macros de autoconf
m4* es un lenguaje de macros. Basicamente toma un file de input y macros
y expande el input. autoconf* usa macros similares a los de m4*. Veamos
algunos ejemplos:
AC DEFUN( FUNCION NAME, BODY )
define una función llamada FUNCTION NAME cuyo cuerpo es BODY.
Cuando m4 encuentra FUNCTION NAME la expande reemplazando con
BODY.
AC TRY RUN( PROGRAM, ACTION-IF-TRUE*, ACTION-IF-FAIL* )
compila un programa en C. Si compila, corre y hace un exit(0) lleva a cabo
ACTION-IF-TRUE. Sino ejecuta ACTION-IF-FAIL.
AC DEFINE( VARIABLE, VALUE*, DESCRIPTION* )
define una variable de preprocesador C mediante un #define como resultado de
un test.
En autoconf.info hay una lista de macros ya definidos por autoconf que se
pueden usar en configure.in.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Algunos macros de autoconf
Cada linea de configure.in es un macro. Cada macro corresponde un chequeo
y dependiendo del resultado se setean algunas variables.
AC_DEFUN( AC_C_BIGENDIAN, [
AC_CACHE_CHECK( whether byte ordering is bigendian, ac_cv_c_bigendia
[ ac_cv_c_bigendian=unknown
...
if test $ac_cv_c_bigendian = unknown; then
AC_TRY_RUN( [ main () {
/* Are we little or big endian? From Harbison&Steele. */
union
{
long l;
char c[sizeof (long)];
} u;
u.l = 1;
exit (u.c[sizeof (long) - 1] == 1);
}], ac_cv_c_bigendian=no, ac_cv_c_bigendian=yes)
fi
] )
if test $ac_cv_c_bigendian = yes; then
AC_DEFINE(WORDS_BIGENDIAN)
fi
] )
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
1b. Escribo Makefile.am
CFLAGS1=@CFLAGS@ -Wall
DEFAULT_FONT_PATH = @fontpath@
...
EFENCE_LIB = @efence_lib@
FLAGS1 = $(CFLAGS1) -I$(top_srcdir)/librio500 @GLIB_CFLAGS@ $(CPPFLAGS
FLAGS2 = -DDEFAULT_PSF_FONT=\"$(DEFAULT_PSF_FONT)\" ..
CFLAGS = $(FLAGS1) $(FLAGS2) $(USB_CFLAGS)
LDADD = $(USB_LIBS) -L../librio500 @GLIB_LIBS@ -lrio500_api \
-lrio500 $(EFENCE_LIB)
GETOPT_FILES = getopt.c getopt1.c
bin_PROGRAMS = rio_format rio_add_song ... bmp2rioani
rio_format_SOURCES = rio_format.c $(GETOPT_FILES)
rio_add_song_SOURCES = rio_add_song.c $(GETOPT_FILES)
...
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
2. Corriendo automake* genero Makefile.in
Makefile.in
generado por automake* a partir de Makefile.am:
# Makefile.in generated automatically by automake 1.5 from Makefile.am
srcdir
prefix
..
EXEEXT
OBJEXT
..
= @srcdir@
= @prefix@
= @EXEEXT@
= @OBJEXT@
# extensiones: nada en Unix, .exe DOS, etc.
# extensiones: .o en Unix, .obj DOS, etc.
# reglas para rio_format
rio_format_OBJECTS = rio_format.$(OBJEXT) getopt.$(OBJEXT) getopt1.$(O
rio_format_LDADD = $(LDADD)
rio_format_DEPENDENCIES =
rio_format_LDFLAGS =
..
rio_format$(EXEEXT): $(rio_format_OBJECTS) $(rio_format_DEPENDENCIES)
@rm -f rio_format$(EXEEXT)
$(LINK) $(rio_format_LDFLAGS) $(rio_format_OBJECTS) $(rio_form
...
@varname@
son completadas por configure* cuando corre.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
3. Corriendo autoheader* genero config.h.in
El comando autoheader* revisa configure.in buscando macros de la forma
AC DEFINE() y genera un archivo config.h.in con cada variable definida
con un comentario y con un #undef:
/* librio500/config.h.in. Generated from configure.in by autoheader.
...
/* ID3 Support */
#undef USE_ID3_TAGS
/* And now the rest of the boys */
#undef ENABLE_NLS
#undef HAVE_CATGETS
#undef HAVE_GETTEXT
...
/* Define to 1 if using ‘alloca.c’. */
#undef C_ALLOCA
/* Define to 1 if translation of program messages to the user’s native
language is requested. */
#undef ENABLE_NLS
...
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
4. Corriendo autoconf* genero configure*
El comando autoconf* lee configure.in, expande todos los macros y genera
configure*.
Una vez generado: corriendo configure* se generan un Makefile por cada
Makefile.in y config.h por cada config.h.in:
/* librio500/config.h. Generated by configure. */
/* librio500/config.h.in. Generated from configure.in by autoheader.
/* These are standard for all packages using Automake */
#define PACKAGE "rio500"
#define VERSION "0.8"
/* USBDEVFS Support */
/* #undef WITH_USBDEVFS */
/* ID3 Support */
/* #undef USE_ID3_TAGS */
/* And now the rest of the boys */
#define ENABLE_NLS 1
/* #undef HAVE_CATGETS */
#define HAVE_GETTEXT 1
...
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
cvs - Concurrent Versions System
Cuando mucha gente modifica un mismo programa o cuando queremos mantener versiones anteriores de un programa debemos usar cvs.
Del man page:
”CVS is a version control system, which allows you to keep
old versions of files (usually source code), keep a log of who,
when, and why changes occurred, etc., like RCS or SCCS.
Unlike the simpler systems, CVS does not just operate on
one file at a time or one directory at a time, but operates on
hierarchical collections of directories consisting of version
controlled files. CVS helps to manage releases and to control
the concurrent editing of source files among multiple authors.
CVS allows triggers to enable/log/control various operations
and works well over a wide area network.
cvs keeps a single copy of the master sources. This copy is
called the source “repository”; it contains all the information to permit extracting previous software releases at any time
based on either a symbolic revision tag, or a date in the past.”
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
cvs - Concurrent Versions System
Para poder usar cvs* hace falta tener una cuenta en un servidor de cvs*. Cuando
se tiene acceso sólo de lectura se usan los siguientes comandos:
cvs login: Antes de utlizar cualquier comando hay que validarse contra el servidor de CVS. Una vez logeado se es posible realizar las otras operaciones
cvs checkout module: hace un “checkout” del módulo module de CVS.
Tı́picamente para traer todo un directorio con un proyecto la primera vez
que se va a trabajar sobre él.
cvs -z3 update -d: Si estoy parado en el directorio que bajé via CVS puedo
hacer un “update” de los cambios que otros hicieron sobre ese dir. El flag
’-z3’ es para que use compresión al traer los cambios y ’-d’ para que sea
recursivo.
cvs status -v file: Nos da información sobre el archivo file y nos dice en qué
rama estamos trabajando.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
cvs - Concurrent Versions System
Si ahora nosotros tenemos un proyecto que queremos subir a un servidor cvs
donde tenemos una cuenta con acceso de escritura usamos los siguientes comandos:
cvs import module vendor-tag release-tag: Si estamos parados en el directorio
donde están nuestros fuentes usamos este comando para subirlo. module es
el nombre del módulo con que se hacen los checkout, vendor-tag y releasetag son dos tags.
cvs commit file: Una vez que modifiqué un archivo y estoy seguro que anda
debo hacer un “commit” de mis cambios. Uso este comando. Allı́ el CVS
me pedirá que ingrese un comentario. Es muy importante hacerlo para que
quede registrado quien hizo qué cambio.
cvs add file: Agrega un file al repositorio. Pero no actualiza el servidor hasta
que no se hace un commit.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
cvs - Concurrent Versions System
cvs tag -b branch-name: Crea una rama en el repositorio llamada branch-name
a partir de la rama principal. Para poder utilizarla hay que hacer un cvs
checkout
cvs checkout -r branch-name module: Hace un “checkout” de la rama llamada
branch-name.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
diff y patch
Problema:
Solución:
¿Cómo le mandamos cambios/mejoras El comando diff*. Este comando comhecha por nosotros si no tenemos acceso para dos archivos fuentes y genera un
de escritura al CVS?
archivo con la diferencia entre los dos
files.
#include hstdio.hi
main()
{
printf("Hello world!");
}
¡¡Falta el CR!! Lo arreglamos y veamos el $ diff file.c file.c.orig:
5c5
< printf("Hello world!\n");
--> printf("Hello world!");
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
diff y patch
¿Cómo se utiliza en la práctica?
1. Hacemos un cvs checkout o cvs update de los fuentes que queremos modificar.
2. Copiamos el file a modificar, por ejemplo: $ cp file.c file.c.orig
3. Hacemos las modificaciones en file.c
4. Hacemos diff con la versión original y lo redireccionamos a un file:
$ diff file.c file.c.orig ¿ file.diff
5. Le mandamos el diff a la persona responable del proyecto con nuestras
super-modificaciones.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Internationalization y localization
¿Qué es i18n y l10n?
i18n (internationalization) es la operación que hay que hacer para que nuestro
programa pueda ser fácilmente traducido a otros idiomas. l10n (localization)
es la operación que hay que hacer para que el input/output de nuestro programa
puede adaptarse fácilmente a las convenciones culturales de distintas regiones
del mundo.
En los proyectos GNU se utiliza el paquete gettext. Veremos una pasada rápida
a los pasos que hay que hacer para que nuestro fuente utilize gettext
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Internationalization y localization
1. Modificar fuentes
1a agregar #include <libintl.h> y #include <locale.h>
1b agregar código de inicialización:
int
main (argc, argv)
int argc;
char argv;
{
...
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
...
}
PACKAGE y LOCALEDIR deben ser definidas mediante ’-D’ en la compilación o estar en config.h si se usa autoconf. Por ejemplo:
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Internationalization y localization
1. Modificar fuentes (cont)
1c agregar #define (String) gettext (String) en algún lugar y marcar
todos los strings que queremos sea posible traducir:
Si en algún lugar tenemos:
...
printf ("Error!! No se pudo hacer tal o cual cosa.");
...
se debe modificar por:
...
printf (_("Error!! No se pudo hacer tal o cual cosa."));
...
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Internationalization y localization
2. Generar el .pot con xgettext
Corriendo xgettext -a sobre mis fuentes obtengo un archivo de tipo .pot con
los strings que quiero convertir.
# Comentarios...
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2002-02-20 02:59+0000\n"
...
#: librio500/anim.c:73
msgid "Setting animation."
msgstr ""
#: librio500/anim.c:98
msgid "Removing Animation."
msgstr ""
...
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Internationalization y localization
3. Generar los .po para cada LOCALE
Copiar el .pot al idioma que quiero modificar y traducir. Por ejemplo:
$ cp PACKAGE.pot es AR.po.
4. Compilar el programa
5. Generar los .mo e instalarlos
Para generar los .mo ejecutar: $ msgfmt -o es AR.mo es AR.po. Luego instalarlos en LOCALEDIR.
Para ver los resultados basta setear la variable LC MESSAGES al locale deseado y correr la aplicacion:
$ export LC MESSAGES="es AR"
$ ./app
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Ant
Ant tiene funcionalidad similar a la de make pero con algunas diferencias importantes:
• Ant está mas bien orientada hacia Java.
• makefiles usa comandos shell para trabajar por lo que dependen de la
plataforma donde se escribió. Ant. utiliza tareas escritas en Java.
• Ant utiliza el formato XML para el ‘makefile’.
• Se agregan modulos nuevos escribiendo clases Java.
Ant tiene montones de ‘tareas’ ya armadas para hacer distintas cosas. Veamos
algunos ejemplos interesantes:
• Acceder a repositorios CVS.
• Corre Jar, gunzip, rpm, Tar, etc. sobre un set de files.
• Manda mail!
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Ant: ejemplo
Un ejemplo simple
Los archivos de Ant se suelen llamar build.xml. Veamos un ejemplo:
Después de la parte general se definen targets que equivalen a las reglas de
make. Para ejecutar ant se hace:
$ ant target
donde target es la regla que se quiere ejecutar.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Ant: targets
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales
Glade
• Genera código C para GTK/GNOME
• Guarda XML que puede ser leido dinámicamente
• Genera todos los files necesarios para autoconf automáticamente.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales
Anjuta
• IDE para GTK/GNOME - C,C++
• Debugger interactivo
• Editor integrado con syntax highlighting, documentación, etc.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales
KDevelop
• IDE para QT/KDE
• Class browser, Wizards
• Editor integrado con syntax highlighting, documentación, etc.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales
Kylix
• IDE cross-platform Linux/Windoze: C++ y Delphi
• Gratis para proyectos GNU
• Muy similar al Borland C Builder
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales: Java
Netbeans (Sun)
• Mas que una IDE: un framework expandible. Soporte principalmente para
Java pero también C, HTML, XML
• Server HTTP incorporado, soporte para JSP, CORBA, RMI, ANT
• JDBC, Servlets, CVS
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales: Java
Netbeans: Poseidon
• Módulo para Netbeans, comercial, para desarrollo de UML.
• Generacón de código Java o C a partir del UML y templates (genera clases
y getter/putter).
• Generación de documentacón al estilo Javadoc.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales: Java
Eclipse (IBM)
• Mas que una IDE: una plataforma para desarrollos.
• Soporte Java, C, C++, Cobol, y otros. Refactoring.
• Sistema de plug-ins para expansión
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Herramientas visuales: Java
Eclipse: Stellation Virtual Source File (VSF) Demo
• Prototipo de un editor VSF
• VSF: un fuente ‘virtual’ compuesto por multiples fragmentos de otros
fuentes, anotaciones, resutlados de pruebas, emails, etc.
• Permite trabajar sobre el VSF como si fuese un único documento.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Sourceforge - http://sf.net
Facilidades:
• Acceso a un CVS ‘individual’, bugtracking, listas de correo
• cuentas ssh, webhosting, ftp, compiler farm
• Patch tracking system, etc.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Sourceforge - http://sf.net
Administración de proyectos:
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Freshmeat - http://freshmeat.net
Catálogo de proyectos:
• Permite anunciar releases nuevos.
• Categorizar mi programa.
• Buscar proyectos similares por todo tipo de criteriors.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Conclusiones
• Hay muchisimos proyectos interesantes para colaborar.
• Hay muchas areas donde se puede aportar: código, documentación, traducciones, etc.
• Todas las herramientas son gratis y están a la mano de cualquiera con acceso
a Inet.
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit
Referencias
• automake, et.al:
• KDevelop:
info automake, info autoconf
• CVS:
• Kylix:
man cvs, info cvs
http://www.borland.com/kylix
• I18n y l18n:
• Netbeans:
info gettext
xgettext -h, msgfmt -h
http://www.kdevelop.org
http://www.netbeans.org
y man
• Ant:
http://ant.apache.org
• Glade:
http://glade.gnome.org
• Anjuta:
• Eclipse:
http://www.eclipse.org
• Sourceforge:
http://www.sourceforge.net
• Freshmeat:
http://freshmeat.net
http://anjuta.sourceforge.net
•First •Prev •Next •Last •Go Back •Full Screen •Close •Quit