delphi msbuild build-process

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



msbuild build-process (6)

Copiar-Compilar-Eliminar

  • Pro: solo una copia oficial de cada archivo, para editar.
  • Pro: Debugger 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 colocamos en la "Ruta de navegación".
  • Pro: el intercambio de archivos se puede gestionar archivo por archivo.
  • Pro / Con: cada proyecto de consumidor puede afectar independientemente 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 la reescritura de algunas de las reglas de MSBuild de Delphi.

¿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
    • Agregar una nueva dependencia de uso compartido debe requerir una declaración explícita para que se administre el uso compartido.
    • Agregar una nueva dependencia compartida aún debería ser relativamente simple; no debería requerir un proceso complicado.
      • Un archivo que enumere todos los archivos "importados" del proyecto (desde el exterior) sería agradable.
  • Tiempo de compilación
    • Todos los proyectos siempre deben compilarse con la versión actual (actual a partir del estado de sincronización de origen más ediciones locales).
      • (El mantenimiento de diferentes versiones en diferentes ubicaciones debe usar la bifurcación de archivos, que no es el tema aquí).
    • Es discutible si cada proyecto debería poder afectar la compilación del archivo compartido con diferentes configuraciones del compilador (incluidos los indicadores).
      • 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 hacer arreglos de mantenimiento (es decir, a corto plazo) si el alcance de dichos cambios se puede restringir fácilmente a un proyecto.
  • Tiempo de depuración
    • La versión correcta de la fuente debería abrirse automáticamente al entrar en una rutina o establecer un punto de interrupción.
    • La edición de la fuente mostrada debería afectar la próxima compilación.
      • No queremos depurar contra una copia temporal de la fuente: probablemente perderíamos el código, en la confusión.

Consideraciones:

  • Término cercano:
    • ¿Qué enfoque será el más simple de poner en marcha?
  • A largo plazo:
    • ¿Qué enfoque será el más simple de usar y mantener?

¡Gracias de antemano por su colaboración!

Mattias

--- ACTUALIZACIÓN ---

¡Gracias por sus comentarios, a través de respuestas, comentarios y votos!

Empecé 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.

¡Manténganse al tanto! (Pero no contengas la respiración; ¡te asfixiarás en cuestión de minutos!: P)

Copy-on-compile

  • Pro: el intercambio de archivos se puede gestionar archivo por archivo.
  • Pro / Con: cada proyecto de consumidor puede afectar independientemente el tiempo de compilación.
  • Con: Debugger enlazará 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 la reescritura de algunas de las reglas de MSBuild de Delphi.

Usar la función de uso compartido de archivos del sistema de control de código fuente

  • Pro: Rápido y fácil de configurar, si el sistema SCM lo admite.
  • Pro / Con: cada proyecto de consumidor puede afectar independientemente el tiempo de compilación.
  • Con: No hay una ubicación oficial, en la copia de trabajo local de las fuentes.
    • Esto puede llevar a confusión.
  • Con: los cambios en la fuente no se reflejan en otras ubicaciones hasta el registro y la recuperación.
    • Para verificar correctamente otros proyectos, antes de registrarse, es posible, pero un dolor real en el trasero.
  • Con: No todos los sistemas SCM admiten archivos compartidos.
    • La función más cercana de Subversion es svn: external.

(Editar: Retitulado esto para evitar confusiones. ¡ Por supuesto , todos deberían usar el Control de código fuente! :-))

Use un proyecto de biblioteca

  • Pro: Solo una copia de cada archivo para editar potencialmente.
  • Pro: solo una compilación, para cada archivo fuente.
    • Menos tiempo para compilar.
    • Compilación consistente entre proyectos dependientes
    • Construcciones incrementales naturales.
  • Pro: Debugger naturalmente se vincula a la fuente adecuada.
    • TODO: Confirmar
  • Pro / Con: los proyectos de los consumidores no pueden afectar independientemente el tiempo de compilación.
  • Con: puede ser difícil administrar el uso compartido a nivel de archivo por archivo.
    • TODO: Investigar
  • Con: podría tomar un esfuerzo significativo para configurar.
    • Configuración de proyectos de MSBuild.
    • La configuración requerida del proyecto debe estar centralizada y estos cambios deben ser verificados.

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

  1. Separe el código fuente a las carpetas.
  2. Crea paquetes para unidades lógicas de código compartido.
  3. Monolito de soporte (sin usar paquetes) y construcciones divididas.
  4. Las versiones monolíticas 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 mediante rutas de búsqueda de proyectos.
  6. La creació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.

PS Usamos paquetes no para controlar dependencias, pero debido a las versiones de Windows que no son NT, tenemos problemas para ejecutar aplicaciones grandes. 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.

No estoy seguro si entendí la pregunta correctamente. De todos modos, cuando creamos un paquete de aplicaciones (varios proyectos pero muchos códigos comunes), creamos una estructura de carpetas como esta:

/Main /Project1 /Project2 ... /CommonUnits

Agregamos unidades comunes a proyectos relevantes (independientemente de que no estén 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 que es importante: en este caso, es mejor tener un repositorio de control de fuente para todo el conjunto (raíz es / Principal, por supuesto).