Organización de los archivos de un proyecto (parte 2)

En en el post anterior comenté sobre los motivos para organizar los archivos de un proyecto de una forma más estructurada que la que ofrece ZinjaI al crear un proyecto, y sobre una estructura de subcarpetas más o menos habitual en proyectos medianos. Ahora toca ver cómo adaptar el proyecto de ZinjaI a esta nueva organización.

Organización de los archivos de un proyecto (parte 1)

Casi todas las plantillas de proyecto de ZinjaI crean una única carpeta en la que los fuentes, el archivo de proyecto y eventuales extras van juntos, y solo se separan en una subcarpeta (debug/release) los archivos generados en la compilación. Esto es lo más directo para empezar, y funciona bien cuando es un proyecto pequeño.

Pero cuando los binarios empiezan a requerir archivos de datos/recursos, el proyecto crece y tenemos varias decenas de fuentes, la arquitectura se complejiza y empezamos a dividir en módulos o bibliotecas, etc; entonces esa organización se vuelve engorrosa, la carpeta del proyecto, una ensalada; y hay que hacer algo al respecto.

La mayoría de los alumnos no considera esto hasta que es demasiado tarde, simplemente por falta de experiencia (o al menos eso me pasó a mí y lo aprendí por las malas).

¿Qué va en el instalador?

Supongamos que hicimos una aplicación con ZinjaI, y ahora la queremos distribuir. No vamos a pretender que cualquier usuario que quiera usar la aplicación deba instalar ZinjaI, los complementos y conseguirse el código fuente, ¿no? ¿No? ¿Nooo? !NO! Lo razonable es armar un instalador que copie en el sistema del usuario el ejecutable de nuestra aplicación y cualquier otra cosa que esta necesite. De eso habla este post; de cómo generar ese ejecutable y cómo determinar qué más necesita.