¿Cuáles son las ventajas de los scripts de compilación?

Automatización.

Cuando esté desarrollando, solo en los proyectos más simples el botón "construir" predeterminado hará todo lo que necesita hacer; es posible que necesite crear WS a partir de API, generar documentos, vincular con recursos externos, implementar los cambios en un servidor, etc. Algunos IDE le permiten personalizar el proceso de compilación agregando pasos o constructores adicionales, pero eso solo significa que está generando su script de compilación a través de los productos IDE.

Pero desarrollar un sistema no es solo escribir código. Hay múltiples pasos involucrados. Un script independiente de IDE se puede ejecutar automáticamente, lo que significa que:

• Cuando confirma un cambio en el control de versiones, el servidor puede iniciar automáticamente una nueva compilación. Se asegurará de que no ha olvidado cometer nada necesario para la compilación.

• Del mismo modo, después de que se realiza la compilación, las pruebas se pueden ejecutar automáticamente para ver si se rompió algo.

• Ahora el resto de la organización (QA, sysadmins) tiene un producto creado que

  a) es perfectamente reproducible solo desde la versión de control.

  b) es común a todos ellos.

Incluso cuando he estado trabajando como un equipo de un solo hombre, he usado scripts para ese propósito; cuando hubiera desarrollado la solución, me comprometería a SVN, exportaría el SVN de nuevo a otro directorio y usaría el script de compilación para generar la solución, que luego iría a los sistemas de preproducción y luego a la producción. Si unas semanas más tarde (con mi base de código local ya cambiado) alguien se quejó de un error, sabría exactamente qué revisión de SVN tendría que pagar para depurar correctamente el sistema.

Como el código, la computadora ejecuta un script de compilación. Las computadoras son excepcionalmente buenas al seguir un conjunto de instrucciones. De hecho, (fuera del código de auto-modificación), las computadoras ejecutarán la misma secuencia de instrucciones exactamente de la misma manera, dada la misma entrada. Esto ofrece un nivel de consistencia que, bueno, solo una computadora puede igualar.

Por el contrario, las bolsas de carne llenas de agua son simplemente despreciables cuando se trata de los siguientes pasos. Ese molesto cerebro analítico tiene una tendencia a cuestionar todo lo que encuentra. "Oh ... no necesito eso", o "¿Realmente uso esta bandera? Eh ... Simplemente la ignoraré". Además, tenemos una tendencia a ser complacientes. Una vez que hemos hecho algo varias veces, empezamos a creer que conocemos las instrucciones y no tenemos que mirar la hoja de instrucciones.

De "El programador pragmático":

  

Además, queremos garantizar la coherencia y la repetibilidad en el proyecto. Los procedimientos manuales dejan la coherencia al cambio; la repetibilidad no está garantizada, especialmente si los aspectos del procedimiento están abiertos a la interpretación de diferentes personas.

Además, somos extremadamente lentos en ejecutar instrucciones (en comparación con una computadora). En un proyecto grande, con cientos de archivos y configuraciones, llevaría años ejecutar manualmente todos los pasos en un proceso de construcción.

Te daré un ejemplo del mundo real. Estaba trabajando en algún software integrado, donde la mayoría del código se compartía en unas pocas plataformas de hardware diferentes. Cada plataforma tenía un hardware diferente, pero la mayoría del software era el mismo. Pero había pequeñas piezas que eran específicas para cada hardware. Lo ideal es que las piezas comunes se coloquen en una biblioteca y se vinculen a cada versión. Sin embargo, las piezas comunes no se pudieron compilar en una biblioteca compartida. Tenía que compilarse con cada configuración diferente.

Al principio, compilé manualmente cada configuración. Solo tomó unos segundos cambiar entre configuraciones, y no fue tan doloroso. Hacia el final del proyecto, se descubrió un defecto crítico en la parte compartida del código, donde un dispositivo esencialmente se haría cargo del bus de comunicación. ¡Esto fue malo! Muy mal. Encontré el error en el código, lo arreglé y volví a compilar todas las versiones. Excepto uno. Durante el proceso de construcción, me distraje y olvidé uno. Los binarios se lanzaron, la máquina se construyó, y un día después recibí una llamada que me decía que la máquina había dejado de responder. Lo comprobé y descubrí que un dispositivo había bloqueado el autobús. "¡Pero solucioné ese error!".

Puede que lo haya arreglado, pero nunca encontró su camino en ese tablero. ¿Por qué? Porque no tenía un proceso de compilación automatizado que compilara todas las versiones con 1 clic.

Si todo lo que quieres hacer es <compiler> **/*.<extension> , los scripts de compilación tienen poco propósito (aunque se puede argumentar que si ves un Makefile en el proyecto, sabes que puedes compilarlo con make ). El problema es que, los proyectos no triviales generalmente requieren más que eso, como mínimo, por lo general, deberá agregar bibliotecas y (a medida que el proyecto madura) configurar los parámetros de compilación.

Los IDE suelen ser al menos configurables, pero ahora el proceso de compilación se basa en opciones específicas de IDE. Si está utilizando Eclipse , Alice prefiere NetBeans , y Bob quiere usar IntelliJ IDEA , no puede compartir el configuración, y cuando uno de ustedes introduce un cambio en el control de origen, debe editar manualmente los archivos de configuración creados por el IDE de los otros desarrolladores o notificar a los otros desarrolladores para que lo hagan ellos mismos (lo que significa que habrá confirma donde la configuración del IDE es incorrecta para algunos de los IDE ...).

También debe descubrir cómo hacer ese cambio en todos y cada uno de los IDEs utilizados por el equipo, y si uno de ellos no admite esa configuración en particular ...

Ahora, este problema depende de la cultura: a los desarrolladores les puede resultar aceptable no tener la opción de IDE. Pero los desarrolladores que tienen experiencia con un IDE suelen ser más felices y más eficientes cuando lo usan, y los usuarios de los editores de texto tienden a ser fanáticos de sus herramientas favoritas, por lo que este es uno de los lugares en los que desea dar libertad a los desarrolladores. - y los sistemas de construcción le permiten hacer precisamente eso. Algunas personas pueden tener una preferencia de sistema de compilación, pero no es tan fanática como las preferencias de IDE / editor ...

Incluso si logra que todos los desarrolladores utilicen el mismo IDE, buena suerte convencerá al servidor de compilación para que lo use ...

Ahora, eso es para las personalizaciones del proceso de compilación simple, para las que los IDE proporcionan una interfaz gráfica de usuario agradable. Si desea elementos más complejos, como el procesamiento previo / la generación automática de archivos de origen antes de la compilación, generalmente tendrá que escribir un script de creación previa en un área de texto básica dentro de la configuración del IDE. En qué sistemas de compilación aún tendría que codificar esa parte, pero puede hacerlo en el editor real en el que escribe el código, y lo que es más importante: el propio marco del sistema de compilación generalmente proporciona cierto apoyo para organizar estos scripts.

Finalmente, los sistemas de compilación son buenos para algo más que construir el proyecto; puede programarlos para que realicen otras tareas que todos los integrantes del equipo puedan necesitar. En Ruby on Rails , por ejemplo, hay tareas del sistema de compilación para ejecutar migraciones de bases de datos, para limpiar los archivos temporales, etc. Poner estas tareas en el sistema de compilación garantiza que todos los miembros del equipo puedan realizarlas de forma coherente.

¡Muchos IDE simplemente empaquetan los comandos utilizados para construir algo y luego generan un script y lo llaman!

Por ejemplo, en Visual Studio, puede ver los parámetros de la línea de comandos para una compilación de C ++ en el cuadro 'línea de comandos'. Si observa detenidamente la salida de compilación, verá el archivo temporal que contiene la secuencia de comandos de compilación que se utilizó para ejecutar la compilación.

Hoy en día, todo es MSBuild , pero aún así es ejecutado directamente por el IDE.

Entonces, la razón por la que usa la línea de comando es que va directo a la fuente y se salta al intermediario, un intermediario que podría haber sido actualizado o requerir un montón de dependencias que simplemente no quiere o no necesita en un servidor sin cabeza que actúa como su servidor de integración continua (CI).

Además, sus scripts hacen más que los pasos habituales orientados al desarrollador para los que están diseñados. Por ejemplo, después de una compilación, es posible que desee que los binarios se empaqueten y copien en una ubicación especial, que se cree un paquete de instalación o que se ejecute una herramienta de documentación en ellos. Muchas tareas diferentes las realiza un servidor de CI que no tiene sentido en una máquina de desarrollador, por lo que si bien puede crear un proyecto IDE que realice todos estos pasos, tendrá que mantener dos de ellas: un proyecto para desarrolladores y otro para compilaciones. Algunas tareas de compilación (análisis estático, por ejemplo) pueden llevar mucho tiempo y no sería conveniente para proyectos de desarrolladores.

Sin embargo, en resumen, es más fácil: cree un script para hacer todas las cosas que desea y es rápido y sencillo comenzar eso en la línea de comandos o en una configuración de servidor de compilación.

make

es mucho más fácil de recordar y escribir que

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

Y los proyectos pueden tener comandos de compilación muy complejos. Un script de compilación también tiene la capacidad de recompilar solo las cosas que cambiaron. Si quieres hacer una compilación limpia,

make clean

es más fácil y más confiable una vez configurado correctamente que tratar de recordar cada lugar donde se haya producido un archivo intermedio.

Por supuesto, si usa un IDE, también puede hacer clic en un botón de compilación o limpieza. Sin embargo, es mucho más difícil automatizar el movimiento del cursor a un lugar específico en la pantalla, especialmente cuando ese lugar puede moverse si se mueve la ventana, que automatizar un comando de texto simple.

¿De qué otra manera lo harías? La única otra forma es especificar un comando de línea de comandos larga.

Otra razón es que los archivos make permiten una compilación incremental, lo que acelera mucho el tiempo de compilación.

Makefiles también puede hacer un proceso de construcción multiplataforma. CMake genera diferentes scripts de construcción basados en la plataforma.

Editar:

Con un IDE, estás atado a una forma particular de hacer las cosas. Muchas personas usan vim o emacs aunque no tienen muchas características similares a IDE. Lo hacen porque quieren el poder que proporcionan estos editores. Los scripts de compilación son necesarios para aquellos que no utilizan un IDE.

Incluso para aquellos que usan un IDE, es posible que desee saber realmente lo que está pasando, por lo que el script de compilación le ofrece los detalles de implementación que un enfoque GUI no tiene.

Los propios IDE también suelen usar scripts internamente; El botón Ejecutar es solo otra forma de ejecutar el comando make.

Las respuestas anteriores cubren mucho terreno bueno, pero un ejemplo del mundo real que me gustaría agregar (que no puedo agregar como un comentario debido a que no hay karma), es de la programación de Android.

Soy un desarrollador profesional de Android / iOS / Windows Phone, y uso las API de servicios de Google (principalmente Google Maps) un lote .

En Android, estos servicios requieren que agregue un keystore , o un tipo de archivo de ID de desarrollador que le dice a Google que soy quien digo que soy, a una consola de desarrolladores. Si mi aplicación está compilada con un almacén de claves diferente, la sección de Google Maps de la aplicación no funcionará.

En lugar de agregar y administrar una docena de almacenes de claves a la consola del desarrollador, solo uno de los cuales puede usarse para actualizar la aplicación de todos modos, lo incluyo en nuestro repositorio seguro y uso Gradle para decirle a Android Studio qué almacén de claves usar. Al compilar para "depurar" o "liberar". Ahora, solo tengo que agregar dos almacenes de claves a mi consola de desarrolladores de Google, uno para "depurar" y otro para "liberar", y todos los miembros de mi equipo pueden clonar el repositorio y comenzar a desarrollar sin tener que ir al desarrollador consola y agregue el hash SHA de su almacén de claves particular, o peor, haciéndome administrarlos . Esto tiene el beneficio adicional de dar a cada miembro del equipo una copia del almacén de claves de firmas, lo que significa que si estoy fuera de la oficina y se programa una actualización, un miembro del equipo solo debe seguir una lista muy corta de instrucciones para poder enviar un mensaje. actualizar.

La automatización de compilaciones como esta mantiene las compilaciones consistentes y reduce la deuda técnica al reducir el tiempo de configuración cuando obtenemos un nuevo desarrollador, una nueva máquina o cuando tenemos que volver a crear una imagen de la máquina.

Ventajas del script de compilación:

• los cambios parecen código (por ejemplo, en un comando de git diff), no como diferentes opciones marcadas en un diálogo

• creando más resultados que una compilación simple

En algunos de mis proyectos anteriores, he usado los scripts de compilación para:

• generar la documentación del proyecto (basada en doxygen)
• construir
• ejecutar pruebas unitarias
• generar informes de cobertura de pruebas unitarias
• empaquetar los binarios en un archivo de lanzamiento
• generar notas de publicación internas (basadas en los mensajes de "git log")
• pruebas automatizadas

A menudo, puede llamar al botón "construir" de forma automatizada (Visual Studio acepta los argumentos de la línea de comandos, por ejemplo). La gente escribe scripts de compilación tan pronto como necesitan algo que el botón de compilación no puede proporcionar.

Por ejemplo, la mayoría de los IDE solo te permitirán crear una plataforma a la vez. O solo un idioma a la vez. Luego está lo que hace con las salidas integradas: ¿puede su IDE agruparlas todas en un paquete de instalación?