Diferencia entre revisiones de «Soporte para otras arquitecturas en Software libre»

De wiki EOI de documentación docente
Saltar a: navegación, buscar
(Página creada con «{{Sección |Título=Soporte para otras arquitecturas |Libro=Software libre |Capítulo=Entornos y tecnologías de desarrollo |Número sección=8 |Introducción=El soporte m...»)
(Sin diferencias)

Revisión del 01:12 28 feb 2012


Estado de desarrollo de la sección: esbozo esbozo

Wikilibro: Software libre > Capítulo 7: Entornos y tecnologías de desarrollo

Sección 8

Soporte para otras arquitecturas
El soporte mínimo para trabajar con un programa portable es el acceso a granjas de compilación, que permiten compilarlo en varias arquitecturas y sistemas operativos. Por ejemplo SourceForge (“SourceForge”) ofreció durante un tiempo entornos Debian GNU/Linux para Intel x86, DEC Alpha, PowerPC y SPARC, además de entornos Solaris y Mac OS/X.

También es útil poder probar (no sólo compilar) el programa en esos entornos. Pero este servicio demanda de más recursos, y de más tiempo de administrador. Ya el mservicio de compilación puede ser problemático, porque habitualmente hay que proporcionar entornos de compilación para varios lenguajes, con una gran cantidad de bibliotecas. Si lo que se quiere es probar un programa cualquiera, las dificultades aumentan exponencialmente, no sólo porque es muy difícil disponer de los recursos requeridos, sino por razones de seguridad, que pueden hacer muy complicado administrar estos sistemas. No obstante existen unos pocos servicios de granja de servidores, con instalaciones estándar de arquitecturas diversas, que pueden permitirnos probar algunas cosas.

Las granjas públicas mencionadas anteriormente suelen ser un servicio de uso manual. El desarrollador invitado copia sus ficheros en una de esas máquinas, los compila y prueba el resultado. Probablemente debe hacerlo de vez en cuando, en el momento previo a la liberación de una versión importante del programa. Puede ser mucho más interesante que las compilaciones y la ejecución de las pruebas de regresión se hagan sistemáticamente, de forma automática, por ejemplo todas las noches, si ha habido cambio en los fuentes. Así funcionan algunos proyectos importantes, que proporcionan una infraestructura propia para desarrolladores externos, que suele llamarse Tinderbox (yesquero). Es el caso de Mozilla, financiado por Netscape, cuyo Tinderbox [moz:tinderbox] presenta una interfaz web a los resultados de la compilación y pruebas de componentes de su navegador en todas las arquitecturas donde funciona. Esta interfaz está íntimamente relacionada con el CVS y muestra esos resultados para distintos estados (entre compromisos), identificando al responsable de los fallos y facilitando el avance, soslayando el problema hasta que se solucione. También usan yesqueros los proyectos OpenOffice y FreeBSD, al menos.

< Sección anterior
Gestión de errores y otros temas

Sección siguiente >
Sitios de soporte al desarrollo