g ++: Use archivos ZIP como entrada

Question

Tenemos la biblioteca de Boost en nuestro lado. Consiste en una gran cantidad de archivos que nunca cambian y solo se utiliza una pequeña porción. Cambiamos todo el directorio de impulso si estamos cambiando las versiones. Actualmente tenemos las fuentes de Boost en nuestro SVN, archivo por archivo, lo que hace que las operaciones de pago sean muy lentas, especialmente en Windows.

Sería bueno si hubiera una notación/plugin para tratar archivos de C++ dentro de archivos ZIP, algo así como:

// @ZIPFS ASSIGN 'boost' 'boost.zip/boost' 
#include <boost/smart_ptr/shared_ptr.hpp> 

¿Hay alguna ayuda para los ganchos del compilador g ++ en? ¿Hay algún esfuerzo con respecto al soporte ZIP? ¿Otras ideas?

Answer 1

Supongo que make o un sistema de compilación similar está involucrado en el proceso de creación de su software. Colocaría el archivo zip en el repositorio y agregaría una regla al Makefile para extraerlo antes de que comience la compilación real.

Por ejemplo, supongamos que su archivo comprimido está en el árbol fuente en "external/boost.zip", y se extraerá a "external/boost", y contiene en su topevel ​​un archivo "boost_version.h" .

# external/Makefile 
unpack_boost: boost/boost_version.h 

boost/boost_version.h: boost.zip 
    unzip $< 

no sé la sintaxis exacta de la llamada unzip, pregunte a su página de manual sobre esto.

Luego en otros Makefiles, puede dejar que sus archivos de origen dependan del objetivo unpack_boost para tener make desempaquetar Boost antes de compilar un archivo de origen.

# src/Makefile (excerpt) 
unpack_boost: 
    make -C ../external unpack_boost 

source_file.cpp: unpack_boost 

Si está utilizando un generador de Makefile (o un buildsystem totalmente diferente), por favor revise la documentación de estos programas para la forma de crear algo así como el objetivo de encargo unpack_boost. Por ejemplo, en CMake, puede usar la directiva add_custom_command.

La letra pequeña: El archivo boost/boost_version.h no es estrictamente necesario para que el Makefile funcione. Podría simplemente poner el comando unzip en el objetivo unpack_boost, pero entonces el objetivo sería efectivamente falso, es decir: se ejecutaría durante cada compilación. El archivo intermedio (que, por supuesto, debe reemplazar por un archivo que está realmente presente en el archivo zip) garantiza que unzip solo se ejecute si es necesario.

Answer 2

Esto es algo que no harías en g ++, porque cualquier otra aplicación que quiera hacerlo también tendría que ser modificada.

Almacenar los archivos en un sistema de archivos comprimido. Entonces, cada aplicación obtiene el beneficio automáticamente.

Answer 3

Debe ser posible en un sistema operativo para permitir el acceso transparente a los archivos dentro de un archivo ZIP. Sé que lo puse en el diseño de mi propio sistema operativo hace mucho tiempo (más o menos 2004) pero nunca llegué a un punto en el que fuera utilizable. La desventaja es que buscar hacia atrás en un archivo dentro de un ZIP es más lento a medida que se comprime (y no puede rebobinar el estado del compresor, por lo que debe buscar desde el inicio en su lugar). Esto también hace que usar un zip-inside-a-zip sea lento para rebobinar y leer. Afortunadamente, la mayoría de los casos solo leen un archivo secuencialmente.

También debe ser adaptable a los sistemas operativos actuales, al menos en el espacio del cliente. Puede enganchar las funciones de acceso al sistema de archivos utilizadas (fopen, abrir, ...) y agregar un conjunto de descriptores de archivos virtuales que su propio software devolvería para un nombre de archivo dado.Si se trata de un archivo real, simplemente pásalo, si no abre el archivo subyacente (posiblemente de nuevo a través de esta misma función) y pasa un identificador virtual. Al acceder al contenido del archivo, léalo directamente desde el archivo zip sin almacenamiento en caché.

En Linux usaría un LD_PRELOAD para inyectarlo en el software existente (en el tiempo de uso), en Windows puede conectar las llamadas al sistema o inyectar una DLL en el espacio del software para conectar las mismas funciones.

¿Alguien sabe si esto ya existe? No puedo ver ninguna razón clara por la que no ...

Answer 4

Hemos estado enfrentando problemas similares en nuestra empresa. Administrar versiones de refuerzo en entornos de compilación nunca será fácil. Con más de 10 desarrolladores, todos codificando en sus propios sistemas, necesitarás algún tipo de automatización.

Primero, no creo que sea una buena idea almacenar copias de grandes bibliotecas como boost en SVN o cualquier sistema SCM para ese asunto, eso no es para lo que esos sistemas están diseñados, excepto si planea modificar el código en boost tú mismo. Pero supongamos que no estás haciendo eso.

Así es como lo gestionamos ahora, después de probar muchos métodos diferentes, esto funciona mejor para nosotros.

Para cada versión de boost que usemos, colocamos todo el árbol (descomprimido) en un servidor de archivos y agregamos subdirectorios adicionales, uno para cada arquitectura/compilación-combinación, donde colocamos las bibliotecas compiladas. Nos guardar copias de estos árboles en todos los sistemas de construcción y en el entorno global del sistema se agregan variables como:

BOOST_1_48=C:\boost\1.48 # Windows environment var 

o

BOOST_1_48=/usr/local/boost/1.48 # Linux environment var, e.g. in /etc/profile.d/boost.sh 

Este directorio contiene el árbol de impulso (. Realce/* HPP) y las libs precompiladas añadidas (por ejemplo, lib/win/x64/msvc2010/libboost_system * .lib, ...)

Todas las configuraciones de compilación (vs soluciones, vs archivos de propiedades, gnu makefiles, ...) definen una variable interna , importando los vars de entorno, como:

BOOSTROOT=$(BOOST_1_48) # e.g. in a Makefile, or an included Makefile 

y otras reglas de compilación, todas utilizan la configuración BOOSTROOT para definir las rutas de acceso incluidas y las rutas de búsqueda de bibliotecas, p.

CXXFLAGS += -I$(BOOSTROOT) 
LFLAGS += -L$(BOOSTROOT)/lib/linux/x64/ubuntu/precise 
LFLAGS += -lboost_date_time 

El motivo para mantener copias locales de boost es la velocidad de compilación. Ocupa bastante espacio en disco, especialmente las librerías compiladas, pero el almacenamiento es barato y un desarrollador que pierde mucho tiempo compilando código no lo hace. Además, esto solo necesita ser copiado una vez.

La razón para usar entornos globales vars es que las configuraciones de compilación se pueden transferir de un sistema a otro y, por lo tanto, pueden registrarse de manera segura en su sistema SCM.

Para suavizar un poco las cosas, hemos desarrollado una pequeña herramienta que se encarga de la copia y la configuración del entorno global. Con una CLI, esto incluso se puede incluir en el proceso de compilación.

Diferentes entornos de trabajo significan diferentes reglas y culturas, pero créanme, hemos intentado muchas cosas y, finalmente, decidimos definir algún tipo de convención. Tal vez la nuestra puede inspirarte ...

Answer 5

Hace un año yo estaba en la misma posición que tú.Mantuvimos nuestra fuente en SVN y, lo que es peor, incluimos el impulso en el mismo repositorio (misma rama) que nuestro propio código. Tratar de trabajar en múltiples sucursales era imposible, ya que tomaría casi un día para sacar una nueva copia de trabajo. Mover el impulso a un repositorio de proveedores por separado ayudó, pero aún tardaría horas en salir.

Cambié el equipo a git. Para darte una idea de cuánto mejor es que SVN, acabo de crear un repositorio que contenga la versión 1.45.0 de boost, luego lo cloné en la red. (La clonación copia todo el historial del repositorio, que en este caso es una confirmación única, y crea una copia de trabajo).

Ese clon tardó seis minutos.

En los primeros seis segundos, una copia comprimida del repositorio se copió en mi máquina. El resto del tiempo lo pasé escribiendo todos esos pequeños archivos.

Lo recomiendo sinceramente que pruebe git. La curva de aprendizaje es abrupta, pero dudo que se haga mucho pirateo previo al compilador en el tiempo que llevaría clonar una copia de refuerzo.