A nivel filosófico, el tema de las compilaciones reproducibles o reproducible builds, es sin duda algo que me preocupaba. Veamos, hay multitud de software de código abierto, pero hasta que punto es verdaderamente abierto, ¿si no hay terceros que sean capaces de recompilarlo y verificar que los resultados obtenidos son idénticos a los oficiales?
Muchos usamos OpenOffice o LibreOffice por ejemplo. Pensamos que son seguros, porque cualquiera puede revisar el código fuente, y encontrar problemas. Lógicamente, el primer requisito, es que el proyecto tenga el código fuente disponible. No necesariamente debe ser libre, pero si que tiene que poder ser revisado. Si el código es cerrado, pues ocurre como la polémica de los motores TDI de Volkswagen.
Después hace falta que alguien esté dispuesto a invertir su tiempo en revisar el código, y que tenga la capacidad de detectar el problema. Sino, recordad el problema de Heartbleed en OpenSSL, que llevaba varios años allí.
Hasta aquí es el punto que todos conocíamos, y que no tiene nada que ver con las compilaciones reproducibles. La iniciativa de Reproducible Builds, lo que pretende es facilitar que ese código fuente, pueda ser verificado como que en efecto genera el ejecutable oficial. Trata de facilitar que gente externa pueda acceder al código, y recompilarlo.
Este proceso, ha sido siempre posible, con mayores o menores dificultadas. Personalmente he compilado SQlite (para DOS y Windows), PHP y extensiones (para Linux), SumatraPDF (para Windows) o ClamAV (para Windows).
Incluso he compilado y contribuido con proyectos más complejos como Netscape, MAME, DOS32/a u OpenWatcom.
He usado sin problemas proyectos de código abierto en mis desarrollo propios. Por ejemplo FileOptimizer contiene binarios de gifsicle, jpegoptim y jsmin compilados por mi. O zRecompress que utiliza el LZMA SDK.
Por tanto el primer objetivo de la iniciativa, es extender el uso de instrucciones de compilación claras, y el acceso a los fuentes. Desgraciadamente, no es suficiente. Hablando desde mi experiencia de proyectos de código abierto que tenéis disponibles en mi página de proyectos en Sourceforge, me refiero a FileOptimizer, TBClamAV, SMETAR, MEMTRACE, XPlorer, ZEROFILL o RLE64 he apoyado ese tipo de iniciativas. Con archivos BAT que automatizaban la construcción, y con el código fuente disponible. Incluso he ido mejorándolo, haciéndolo más fácil en bastantes aspectos, con un repositorio SVN y un mirror en Github.
Ahí es donde entran en juego las compilaciones automatizadas (automated builds), servicios que se encargan de compilar automáticamente nuestros proyectos como la Farm de Sourceforge. Igualmente contamos con herramientas de pruebas continuas (continous test), como Coverity Scan, que es un analizador de código al estilo de CppCheck o Lint. De hecho, hasta contamos con servicios de integración continua (continous integration), que combinan los dos, con servicios como App Veyor o TravisCI.
Para las compilaciones automatizadas, la cosa no es tan sencilla, porque aunque doy el código fuente, explicaciones de como usarlo, y facilito su acceso, suelo utilizar C++ Builder en la mayoría de proyectos (también Delphi, Lazarus
OpenWatcom, Visual C++ o MASM). C++ Builder, es un entorno de desarrollo propietario, y de pago. Igual que Visual C++ y Delphi, lo que exige disponer de él para poder colaborar. Por mucho que el proyecto sea libre y gratuito, las herramientas de desarrollo no lo son, ni siquiera para uso no comercial. Claro que tenemos Visual C++ Express, y C++ Builder Starter o Delphi Starter, pero son tan limitados, que no servirán para la mayoría de proyectos. Eso implica que estos servicios, no disponen de estas herramientas, por lo que son ineficaces.
La solución, sería que Embarcadero, proporcionada licencias gratuitas, de manera que más proyectos de código abierto las utilizaran, pero dudo que lo hagan.
Hace poco que he colaborado con la actualización de la extensión win32service de PHP a la rama 7.x.
https://github.com/InExtenso/win32service
El descubrimiento por mi parte de App Veyor ha sido una bendición, pues me ha permitido compilar una extensión que es muy importante para mi. Cuando en php-5.4 faltaron binarios de dicha extensión ya me lié la manta a compilarla con un Visual Studio Express. Ahora se utiliza el Visual Studio Community que está oficialmente soportado.
Herramientas como App Veyor nos da la posibilidad de realizar compilaciones estandarizadas, ya que todo el mundo utiliza la misma plataforma (o similares) y scripts.
Si un día tengo tiempo explicaré algo más sobre la extensión win32service, que tiene su miga.
Saludos
Pues sí, ese es un gran problema, porque por muy abierto que sea el código, sin las herramientas de desarrollo no se hace nada, que encima no es que no sean gratis, es que son muy caras (y necesitan ordenadores cada vez más potentes, por cierto).
Creo que una solución sería como antiguamente hacían Nokia con sus SDK, o sea, en cierta manera obligar, recomendar -no me gusta mucho el termino «obligar», no sería propio aquí pero bueno- o aconsejar a todo el que desarrolle aplicaciones de ese tipo, usar herramientas de desarrollo también libre. Con los tiempos que corren, y pudiendo contar con cosas como Eclipse para Java (y para otros, como C++ con Neon) o Lazarus para Pascal, o Netbeans, no hace falta irse a IDEs de desarrollos de pago. Y ojo que he hablado de tres que no son moco de pavo, y que con todo merecimiento le dan mil vueltas a cualquier IDE comercial actual.
Me gustaría conocer esa historia Fernando. Y ciertamente, AppVeyor y plataformas similares, ayudan mucho realmente a que el código sea portable, y accesible.
Porque BiaNamaran, tiene mucha razón. Las herramientas de desarrollo suelen ser caras, y requerir un hardware bastante potente, lo que limita su uso a software comercial, porque cuando este es gratis, poco se puede hacer.
Hola Guti, sobre Visual C++ me gustaría comentarte una cosa que ha pasado bastante desapercibida pero me parece que es un gran paso adelante. Microsoft ha publicado el compilador Visual C++ como descarga separada de Visual Studio y de forma gratuita. Es decir, puedes usar Visual C++ por línea de comandos sin necesidad de tener Visual Studio.
http://landinghub.visualstudio.com/visual-cpp-build-tools
Yo lo he estado probando y la verdad que funciona muy bien.
Es interesantísimo Adrián Arroyo. Antiguamente había algo parecido, pero no incluía las librerías, por lo que a efectos prácticos, era inútil. Por lo que veo además, en la 2017 RC de las Visual Studio Build Tools, han agregado también soporte MFC, así que parece una gran alternativa.
Pienso que todos los fabricantes de herramientas de desarrollo comerciales deberían seguir ese enfoque.
Si bien podríamos criticar a Microsoft por muchos y justificados motivos, lo cierto es que en cuanto a sus herramientas de desarrollo siempre han tenido una versión gratuita.
Cuando entré a trabajar en mi actual empresa, allá por finales del siglo 20 (1999), programaba principalmente en Visual Basic y ya por entonces utilicé una versión gratuita llamada «Visual Basic for Components’, que servia para crear ocx y dll que luego se podían utilizar con otros programas… he utilizado en distintos momentos el Visual Studio Express y las principales pegas a la hora de compilar eran que tenían algunas opciones deshabilitadas…
Con Visual Studio Community (VS 2015) han pegado el salto y según creo no tiene restricciones a la hora de compilar.
Sin embargo si que es cierto que los requisitos de hardware cada vez son mayores, y si bien es posible compilar con CPU y RAM escasos, yo lo he hecho en un Atom con 1GB de RAM y VS2012 y mucha paciencia, lo cierto es que los requisitos de almacenamiento con la versión 2015 son demenciales. De hecho son la causa de que no intentara compilar la extensión win32service hasta que encontré el proyecto de Jean y descubrí App Veyor.
Eso me recuerda que curiosamente el desarrollador original ya no tiene una máquina con Windows, y Jean que se propone como mantenedor tampoco dispone de una, sin embargo mediante máquinas virtuales para la depuración y AppVeyor como compilador Jean ha conseguido resolver los problemas (aka bugs) que se han presentado.
Fernando, tu comentario me hace pensar en lo de las nuevas plataformas, y la necesidad de máquinas virtuales. Llevábamos desde la época de los 8 bits, en que el entorno doméstico y empresarial no estaba tan fragmentado, es decir desde la era pre PC.
Ahora con plataformas móviles, el auge de OS X, y la conquista de los sabores de Linux para servidores, hace que tengamos que usar máquinas virtuales. Un poco como antaño ser hacía con emuladores, cuando los juegos para 8 bits solían programarse sobre máquinas de 16 bits.
creo que el problema es que solo nos limitamos muchos a ver el código fuente, pero nunca a recompilarlo.
Manuel, es así. Tenemos un tiempo limitado, y muchas veces un interés que no es suficiente para que lleguemos a modificar y compilar por nosotros mismos un proyecto de otros. Sin embargo en otros casos, el problema es que no tenemos las herramientas necesarias para compilarlo, o simplemente no queremos instalárnoslas, o son incompatibles con nuestro sistema. Es ahí donde este tipo de herramientas funcionan muy bien.