Definir un entorno de tiempo de ejecución

Question

Necesito definir un entorno de tiempo de ejecución para mi desarrollo. La primera idea es, por supuesto, no reinventar la rueda. Descargué macports, usé easy_install, probé fink. Siempre tuve problemas En este momento, por ejemplo, no puedo compilar scipy porque el instalador de MacPorts quiere descargar e instalar gcc43, pero esto no se compila en Snow Leopard. Hay un error abierto para este problema, pero básicamente estoy atado a ellos para que mi tiempo de ejecución sea utilizable.

Una técnica que aprendí hace algún tiempo fue escribir un archivo MAKE para descargar y construir el tiempo de ejecución / libs con versiones claramente especificadas de bibliotecas y utilidades. Esto es anterior al enfoque MacPorts / fink / apt, pero usted tiene mucho más control sobre él, aunque tiene que hacer todo a mano. Por supuesto, esto puede convertirse en una pesadilla por sí solo si el tiempo de ejecución crece, pero si encuentra un problema, puede usar patch y solucionar el problema en el paquete descargado, luego compilarlo.

Tengo varias preguntas:

• ¿Cuál es su técnica para preparar una colección de biblioteca / tiempo de ejecución bien definida para su desarrollo?
• ¿MacPorts / fink / lo que sea me permite la misma flexibilidad de volver a hackear si algo sale mal?
• Teniendo en cuenta mi solución de archivo MAKE, cuando mi software finalmente se descarga, ¿cuáles son sus sugerencias para resolver los posibles problemas entre mi entorno de desarrollo y la plataforma real en las máquinas de mis usuarios?

Editar : lo que no entiendo en particular es que otros proyectos no me dan pistas. Por ejemplo, acabo de descargar scipy, una biblioteca compleja con muchas dependencias. Los desarrolladores deben tener todas las configuraciones del departamento antes de trabajar en él. A pesar de esto, no hay nada en el svn que cree este entorno.

Editar : se agregó una recompensa a la pregunta. Creo que este es un tema importante y merece obtener más respuestas. Consideraré mejor esas respuestas con ejemplos del mundo real con especial atención a cualquier problema que surja y su solución.

Preguntas adicionales para inspirar a Bounty:

• ¿Realiza pruebas en su entorno (para verificar la instalación adecuada, por ejemplo, en una máquina de integración)?
• ¿Cómo incluye su entorno en el momento del envío? Si es C, ¿lo vincula estáticamente o envía la biblioteca dinámica, modificando LD_LIBRARY_PATH antes de ejecutar el ejecutable? ¿Qué pasa con el mismo problema para python, perl y otros?
• ¿Se apega al tiempo de ejecución o lo actualiza a medida que pasa el tiempo? ¿Descarga " trunk " paquetes de sus bibliotecas de dependencias o una versión fija?
• ¿Cómo lidiar con situaciones como: library foo necesita python 2.5, pero necesita desarrollarse en python 2.4 porque la barra de la biblioteca no funciona con python 2.5?

Answer 1

Utilizamos un script CMake que genera Makefiles que descargan (principalmente a través de SVN) / configuran / construyen todas nuestras dependencias. ¿Por qué CMake? Multiplataforma. Esto funciona bastante bien, y admitimos la invocación de scons / autopain / cmake. A medida que construimos en varias plataformas (Windows, MacOSX, un montón de variantes de Linux) también admitimos diferentes indicadores de compilación, etc., basados ??en el sistema operativo. Normalmente, una biblioteca tiene una configuración predeterminada, y si encontramos un sistema que necesita una configuración especial, la configuración se reemplaza con una configuración especializada. Esto funciona bastante bien. Realmente no encontramos ninguna solución lista que se ajustara a nuestro propósito.

Dicho esto, es un PITA ponerlo en funcionamiento: hay muchas perillas para girar cuando necesita soportar varios sistemas operativos. No creo que se convierta en una pesadilla de mantenimiento ya que las dependencias son bastante fijas (las bibliotecas se actualizan regularmente, pero rara vez presentamos una nueva).

Answer 2

virtualenv es bueno, pero no puede hacer magia - p.ej si quieres usar una biblioteca que DEBE tener Python 2.4 y otra que absolutamente NECESITA 2.5 en su lugar, no tienes suerte. Tampoco puede ayudar virtualenv (o cualquier otra herramienta) cuando hay un nuevo lanzamiento de un sistema operativo y la mitad de las herramientas & amp; c aún no lo admiten, como mencionó para Snow Leopard: algunos problemas son simplemente imposibles de resolver (dos bibliotecas con necesidades absolutamente conflictivas dentro de la misma compilación), otras solo requieren paciencia (hasta que todas las herramientas que necesite se porten a la nueva versión del sistema operativo, solo debe seguir con la versión anterior del sistema operativo).