2009-02-27 15 views
6

Tengo un código fuente de aproximadamente 500 archivos en aproximadamente 10 directorios. Necesito refactorizar la estructura del directorio, esto incluye cambiar la jerarquía del directorio o cambiar el nombre de algunos directorios.Reestructuración de directorios C++

Estoy usando svn version control. Hay dos formas de refactorizar: una preservando el historial svn (usando el comando svn move) y la otra sin preservar. Creo que la refactorización de preservar el historial de svn es mucho más fácil usando eclipse CDT y el complemento SVN (el estudio visual no se ajusta en absoluto a la reestructuración de directorios).

Pero ahora que el código no se ha publicado, tenemos la opción de no conservar el historial.

Todavía queda la tarea de cambiar las directivas include de los archivos de encabezado donde sea que estén incluidas. Estoy pensando en escribir un pequeño script usando Python: recibe un mapa del nombre de archivo actual a un nuevo nombre de archivo, y hace el cambio de nombre donde sea necesario (usando algo como sed). ¿Alguien ha hecho este tipo de refactorización de directorios? ¿Conoces buenas herramientas relacionadas?

+0

Esperemos que su base de código utiliza caminos base de la raíz del árbol de origen como # include "tal vez/algún/stuff.h" y caminos no relativas como # include "../../../stuff.h". – bk1e

+0

@ bk1e, sí lo hace. –

Respuesta

3

Si tiene que volver a escribir el #include s para hacer esto, lo hizo mal. Cambie todos sus #includes para usar una estructura de directorios muy simple, con dos niveles de profundidad y solo usando un segundo nivel para organizar alrededor de la arquitectura o dependencias del sistema operativo (como sys/types.h).

A continuación, cambie sus archivos make para usar -I include paths.

Voila. Nunca más tendrás que hackear el código para esto, y las compilaciones explotarán instantáneamente si algo sale mal.

En cuanto a la parte de la historia, personalmente me resulta más fácil comenzar de cero al hacer este tipo de cosas; archivar el anterior, crear un nuevo repositorio v2, ir desde allí. El argumento en contra es cuando hay un montón de historial de cambios, o muchos problemas abiertos contra el código existente.

Ah, y tienes buenas pruebas, y no estás haciendo esto con un lanzamiento que viene, ¿verdad?

+0

De acuerdo: la estructura pertenece a la información de compilación, no al código. Todos los compiladores de Mac permitían especificar un árbol de directorios para que no tuvieras que desplazarte por tantas rutas explícitas. ¡Fue un shock cuando comencé a usar Visual Studio! –

+0

"A continuación, cambie sus archivos make para usar -I incluyen rutas" - Las opciones no deben ser demasiado profundas, pero no me gustaría complicarlas -I ruta. Debería haber contenedores en el nivel superior de cada directorio proporcionando "fachadas" para el directorio. Esta es la forma en que Boost funciona; usarlo solo necesita incluir solo un directorio. –

+0

no creo que sea demasiado importante, que forma en que lo hace, pero el archivo de envoltura significa que tiene que leer el código de entender cómo funciona la acumulación; Prefiero ser capaz de encontrar todo en el Makefile. –

2

Preservaré la historia, incluso si toma una pequeña cantidad de tiempo extra. Hay mucho valor en poder leer los registros de commits y entender por qué la función X está escrita de una manera extraña, o que este es un error "off-by-one" porque fue escrito por Oliver, quien siempre se equivoca.

El argumento en contra de la preservación de la historia se puede hacer para los siguientes usuarios:

  • su código podría tener cosas embarazosas, como malas palabras y los combates entre los desarrolladores
  • que no les importa acerca de la historia de comprometerse su código, porque no va a cambiar o mantenerse en el futuro

Realicé algunas refactorizaciones de directorios como esta el año pasado en nuestra base de códigos. Si su código está razonablemente estructurado al principio, puede hacer entre el 75 y el 90% del trabajo usando scripts escritos en el idioma de su elección (utilicé Perl). En mi caso, pasamos de un conjunto de archivos en un gran directorio a una serie de directorios anidados que dependen de los espacios de nombres. Por lo tanto, un archivo que declaró la clase protocols :: serialization :: SerializerBase se encuentra en src/protocols/serialization/SerializerBase. El mapeo del antiguo nombre al nuevo era trivial, por lo que hacer un find y replace en #includes en cada archivo fuente en el árbol era trivial, aunque fue un gran cambio.Hubo un par de casos extremos que tuvimos que arreglar a mano, pero eso parecía mucho mejor que tener que hacerlo todo a mano o tener que escribir nuestro propio analizador de C++.

2

Hackear un script de shell para hacer el svn movimientos es trivial. En tcsh es foreach F ($ FILES) ... fin para ajustar un conjunto de archivos. Perl & Python ofrece una mejor utilidad.

Realmente vale la pena guardar la historia. Especialmente cuando intentamos rastrear algún error exótico. Aquellos que no aprenden de la historia están condenados a repetirla, o algo así ... no deseado

En cuanto a la alteración de todos los archivos ... No era una pregunta similar, el otro día más en:

https://stackoverflow.com/questions/573430/ c-include-header-path-change-windows-to-linux/573531#573531