¿Cuál es la mejor manera de compartir archivos fuente Delphi entre proyectos?

Question

¿Cuál es la mejor forma de compartir archivos fuente Delphi entre proyectos?

Aclaración: Queremos utilizar un solo archivo fuente en múltiples proyectos Delphi. Hemos estado utilizando nuestra herramienta SCM para colocar el mismo archivo en varias carpetas, pero esta no es una experiencia súper elegante y también estamos considerando migrar a una herramienta que no sea compatible con esto.

Como he estado investigando esta cuestión, he considerado algunos enfoques diferentes, pero me gustaría saber qué está haciendo y cómo encuentra su enfoque.

escenarios importantes:

• Código de tiempo
  • Adición de una nueva dependencia intercambio debe requerir declaración explícita, por lo que se gestiona el intercambio.
  • Añadir una nueva dependencia de uso compartido debería ser relativamente simple; no debería requerir un proceso complicado.
    • Un archivo que enumera todos los archivos "importados" del proyecto (desde el exterior) sería agradable.
• tiempo de compilación
  • Todos los proyectos siempre deben construir con la versión actual (válida a partir del estado de sincronización fuente más ediciones locales).
    • (Mantener diferentes versiones en diferentes lugares debe usar el archivo de ramificación, que no es el tema, aquí.)
  • sea cada proyecto debe ser capaz de afectar a la compilación del archivo compartido con diferentes ajustes del compilador (incluyendo banderas) es discutible.
    • Es posiblemente más fácil de mantener (es decir, a largo plazo) el código fuente que siempre se crea de forma coherente.
    • Podría decirse que es más fácil realizar arreglos de mantenimiento (es decir, a corto plazo) si el alcance de dichos cambios se puede restringir fácilmente a un proyecto.
• depuración en tiempo
  • La versión correcta de la fuente debería abrir automáticamente, al entrar en una rutina o la creación de un punto de ruptura.
  • La edición de la fuente mostrada debería afectar a la siguiente compilación.
    • No queremos depurar contra una copia temporal de la fuente: probablemente perderíamos el código, en la confusión.

Consideraciones:

• CORTO PLAZO:
  • ¿Qué enfoque será más simple para poner en su lugar?
• a Largo Plazo:
  • ¿Qué enfoque será más sencillo de utilizar y mantener?

Gracias, de antemano, por su colaboración!

Mattias

---

--- --- ACTUALIZACIÓN

Gracias por su colaboración, a través de respuestas, comentarios y votos!

He comenzado por el camino de poner archivos compartidos en un proyecto de "productor" e importar una lista de archivos compilados en cada proyecto de "consumidor". Los proyectos están siendo vinculados junto con MSBuild. Una vez que las cosas estén más definidas, editaré esta pregunta y la respuesta del "Proyecto de biblioteca" para compartir lo que he aprendido.

¡Estén atentos! (Pero no contener la respiración; podrás asfixian en cuestión de minutos!: P)

Answer 1

uso compartido de archivos origen de elemento del sistema de control de

• Pro: Rápido y fácil de configurar, si el SMC el sistema lo admite.
• Pro/Con: Cada proyecto de consumidor puede afectar de forma independiente el tiempo de compilación.
• Con: No hay una ubicación oficial, en la copia de trabajo local de las fuentes.
  • Esto puede causar confusión.
• Con: Los cambios de origen no se reflejan en otras ubicaciones hasta el registro y la recuperación.
  • Para verificar correctamente otros proyectos, antes del checkin, es posible, pero un dolor real en el trasero.
• Con: No todos los sistemas SCM admiten archivos compartidos.
  • La característica más cercana de Subversion es el nivel de carpeta svn: externals.

(Editar: tituló de nuevo esto para evitar confusión.Por supuesto, todos deberían usar Control de fuente! :-))

Answer 2

Copy-on-compile

• Pro: Uso compartido de archivos se puede archivo por archivo gestionado.
• Pro/Con: Cada proyecto de consumidor puede afectar de forma independiente el tiempo de compilación.
• Con: Debugger se vinculará a la copia temporal, no a la versión oficial.
  • TODO: Vea si hay alguna manera de cambiar esto.
• Con: Puede tomar algún trabajo para configurar los proyectos de MSBuild.
• Con: Puede ser difícil crear incrementalmente archivos compartidos.
  • Puede implicar volver a escribir algunas de las reglas de MSBuild de Delphi.

Answer 3

Copy-compilar-Delete

• Pro: Sólo una copia oficial de cada archivo, editar.
• Pro: El depurador no se vinculará a la copia temporal, ya que se ha eliminado por la depuración.
  • TODO: Compruebe que el depurador encontrará la fuente original, si lo ponemos en la "Ruta de navegación".
• Pro: El uso compartido de archivos se puede gestionar archivo por archivo.
• Pro/Con: Cada proyecto de consumidor puede afectar de forma independiente el tiempo de compilación.
• Con: Puede tomar algún trabajo para configurar los proyectos de MSBuild.
• Con: Puede ser difícil/imposible construir incrementalmente archivos compartidos.
  • Puede implicar volver a escribir algunas de las reglas de MSBuild de Delphi.

Answer 4

Usar un proyecto de biblioteca

• Pro: Sólo alguna vez una copia de cada archivo que potencialmente edición.
• Pro: Solo una compilación, para cada archivo fuente.
  • Menos tiempo para compilar.
  • compilación consistente entre proyectos dependientes.
  • Compilaciones incrementales naturales.
• Pro: Debugger naturalmente vincula a la fuente adecuada.
  • TODO: Confirmar.
• Pro/Con: Los proyectos de consumo no pueden afectar de forma independiente el tiempo de compilación.
• Con: Puede ser difícil de administrar compartir en un nivel de archivo por archivo.
  • TODO: Investigar.
• Con: Podría requerir un gran esfuerzo de configuración.
  • Configuración de proyectos de MSBuild.
  • La configuración del proyecto requerida debe estar centralizada y estos cambios deben verificarse.

Answer 5

creo que no se requieren soluciones especiales. En nuestro proyecto (varias aplicaciones que comparten grandes áreas de código) utilizamos el siguiente enfoque:

1. Divide el código fuente en las carpetas.
2. Crea paquetes para unidades lógicas de código compartido.
3. Monolito de soporte (sin usar paquetes) y versiones divididas.
4. Las compilaciones de Monolith se utilizan para la codificación y la depuración. Cada aplicación tiene su propio directorio de salida de la Unidad, por lo que todos se crean de forma independiente.
5. Las restricciones de dependencia se aplican por las rutas de búsqueda de los proyectos.
6. La construcción dividida se crea automáticamente (usamos el servidor CruiseControl y el proyecto MSBuild). La creación automática borra todas las carpetas temporales antes de la compilación, por lo que no hay dependencias entre compilaciones consecutivas.

En nuestro caso, no pudimos controlar la lista de archivos importados. Sin embargo, podríamos controlar una lista de paquetes importados en compilaciones partidas. Los paquetes más pequeños significan una mejor granularidad. Si alguien está agregando dependencia a la unidad, ubicada en una carpeta que no está disponible en la ruta de búsqueda, y el paquete que contiene esta unidad no está en la lista de usos, la construcción dividida ha fallado. Por lo tanto, se requiere una acción explícita (modificación del script de MSBuild que genere archivos CFG para la compilación dividida) para agregar dependencia.

P.S. Usamos paquetes para no controlar dependencias, pero debido a las versiones de Windows que no son NT, tenemos problemas para ejecutar aplicaciones de gran tamaño. Entonces, el control de dependencia es un efecto secundario. Las compilaciones partidas se consideran como "versión" y monolito, como configuración de "depuración". Las aplicaciones de Monolith solo se utilizan para la codificación y la depuración. Los desarrolladores trabajan con aplicaciones de monolitos e introducen sus propios cambios en las configuraciones de proyectos, como adjuntar información de depuración de VCL, activar y desactivar errores de comprobación de rango, optimización, etc. Sin embargo, después de comprometerse con SVN, CC intenta crear compilación dividida. Ignora los archivos CFG del repositorio y los vuelve a crear mediante una tarea especial del proyecto MSBuild. Por lo tanto, podemos estar seguros de que no se presentaron problemas con las dependencias (y realizar otras comprobaciones también).

En la medida en que no necesitamos monolitos y construcciones divididas simultáneamente, tenemos solo un proyecto por aplicación. Si desea compilar ambas versiones en el script de MSBuild, simplemente puede agregar un objetivo más, volver a crear CFG una vez más y especificar un directorio de salida más. Naturalmente, si se requieren ambas versiones para los desarrolladores, sería más conveniente tener más proyectos.

Answer 6

No estoy seguro de haber entendido la pregunta correctamente. De todos modos, cuando la construcción de conjunto de aplicaciones (varios proyectos, pero gran cantidad de código común), creamos estructura de carpetas como esto:

\Main 
    \Project1 
    \Project2 
    ... 
    \CommonUnits 

Añadimos unidades comunes a los proyectos relevantes (sin tener en cuenta que no es en la misma carpeta que el archivo de proyecto). Además, a veces es más fácil usar definiciones condicionales a nivel de proyecto (Proyecto | Opciones | Directorios/Condicionales) para pequeñas diferencias de código. Por ejemplo, Project1 tendrá algo así como "APP_PROJECT1" definido y luego podrá usar $ IFDEF en unidades comunes para escribir un código específico.

Lo importante: en este caso, es mejor tener un repositorio de control de código fuente para todo el conjunto (raíz es \ Principal, por supuesto).