El proceso de publicar una versión de PSeInt

Últimamente estuve escribiendo sobre los cambios internos de PSeInt. Todavía estoy muy lejos de donde quiero estar en este sentido, pero hice una pausa en un punto razonable como poder sacar una versión. Para actualizar los perfiles, publicar algunas correcciones a bugs u otras mejoras menores, actualizar las opciones de descarga, etc... El mantenimiento que vengo posponiendo hace más de un año.

Pero aún así, aunque el código nuevo anda, todavía no pude publicarlo. ¿Qué me está frenando?

 

Los perfiles

Aunque no lo parezca, agregar los perfiles nuevos que van solicitando los usuarios demanda mucho tiempo. Los recibo por correo y rara vez listos para agregar al repositorio. Usualmente tengo que editar la descripción, elegir un nombre que no se pise con los preexistentes, buscar el sitio web de la institución para obtener un ícono (con suerte en algunos casos lo envían) y ajustarle tamaño y formato, registrar los datos en una planilla interna mía y responder el mail, ubicar los archivos donde corresponde en el repo y documentarlo en el changelog. A veces hasta tengo que intercambiar algunos mails adicionales porque me envían los datos de la institución pero no la configuración del lenguaje.

En fin, digamos que cada perfil me consume de 5 a 10 minutos. Luego de tanto tiempo sin sacar una versión, se me acumularon más de 70 correos solicitando agregar o actualizar perfiles. Son varias horas de trabajo tedioso cargarlos todos. Y no quedaría bien que publique la actualización sin incluir los que llegaron suficientemente a tiempo.

 

Las herramientas de compilación 

Tengo varios toolchains que uso para generar las versiones para los distintos sistemas. Usualmente, como suelo automatizar la mayor parte del empaqueto con scripts de bash, generar una release suele ser bastante rápido. Pero esta vez tuve que actualizar todo porque el nuevo código requiere C++17, y los compiladores que usaba eran demasiado viejos (además de que Apple cambió oootra vez su arquitectura de hardware).

 

En el caso de Windows, usaba el mingw32 que armé para ZinjaI (que se había estancado en gcc6), mediante wine. Ahora planeo lanzar un ZinjaI basado en mingw64 (con 2 versiones, una de 32bits y otra de 64bits). Ya estuve actualizando estos otros scripts que descargan y acomodan estos archivos para ZinjaI.

Pero un cambio de compilador implica también recompilar todos los complementos (y de paso, actualizar sus versiones). Esa es la parte lenta y tediosa. La mitad de las veces hay que ajustar el script de compilación o hacer algún parche para que funcione (lo cual implica googlear un buen rato para entender el error y encontrar/armar el parche). Y para PSeInt necesito algunos de esos complementos (empezando por el de wxWidgets).

 

En el caso de MacOS es todavía peor. Uso un compilador cruzado (una versión de gcc o de clang compilada en GNU/Linux pero que genera binarios para MacOS). Obtener la versión adecuada del SDK de macOS, y compilar el compilador implica varios pasos que nunca funciona a la primera. Y siempre pasan cosas "raras" con los SDKs de MacOS (ejemplo más abajo). 

Actualicé todo esto, y ahora puedo compilar binarios para los nuevos procesadores ARM64. Peeero... No los puedo testear, porque no hay máquina virtual para emular eso en una notebook Intel (y entonces ¿cómo se qué estoy distribuyendo?... todavía no tengo respuesta). Solo pude testear la versión alternativa compilada para procesadores Intel en una máquina virtual con un macOS que ya está bastante viejo.

En el caso de GNU/Linux, las cosas suelen ir más sobre rieles. Porque es la plataforma que compilo nativa, y la que más conozco como para resolver cualquier problema. Aquí empecé teniendo que cambiar de distribución porque ahora la mayoría ya no dan versiones de 32bits (entre ellas Ubuntu, que es la que estaba usando). Pero armé una VM nueva basada en Linux Mint 19 de 32bits, y pude compilar todo.

Luego quise probar con Ubuntus 18.04 LTS y 19.10 para los 64bits pero los repos ya no funcionan, y entonces una vez instalado el sistema base no puedo agregar lo que me falta para compilar wx. Creo que no habría problemas si parto de 20.04 LTS, pero trato de evitarlo porque si uso una versión demasiado "reciente" corro el riesgo de que los binarios dependan de algo relativamente nuevo y no les funcione a los usuarios con sistemas más viejos/desactualizados (que son muchos más de los que deberían). Ya veré si puedo hacer andar algo intermedio.

Y las versiones cada vez son más: win32, win64, mac-arm64, mac-x86_64 (ya deprequé mac-i686 y mac-ppc), linux32, linux64... y podrían aparecer más, como una para Chromebooks, o una para Rapsberry Pi, si supiera cómo hacerlas y probarlas. Pero entonces también tuve que reestructurar los scripts de compilación del propio PSeInt. Ya no era sostenible tener un makefile por módulo y por plataforma. Mejoré esto, pero como todo, también llevó su tiempo.

Lo bueno es que aproveché el tener que reconstruir casi todo para documentar el proceso; muchos detalles ahora están aquí.

Las pequeñas diferencias entre plataformas

Aún en código relativamente básico (que solo usa C++ estándar) me encuentro con problemas al cambiar de compilador. 

Por ejemplo, en macOS, si queremos soportar versiones previas a 10.13*, hay partes muy específicas de la biblioteca estándar que no tendremos disponibles. Me topé con el problema al usar la función std::get (para extraer un dato de un std::variant). Encontrar el por qué del problema ya fue un problema, y luego buscar una corrección que no me obligue a ensuciar todo el código con workarounds por culpa de una sola plataforma también se llevó su tiempo.
*no se si es muy necesario, no estoy familiarizado con el "ecosistema" de macs.

Otro ejemplo apareció al activar C++17 con el nuevo mingw64. Este deriva de una mala práctica que yo tenía cuando empecé a programar: poner el "using namespace std" en headers. Como en C++17 se define un significado para "byte" y Windows en sus propios headers también quiere definir otro significado para "byte", entran en colisión. Nuevamente, entender la raíz del problema lleva un rato de investigar, y después agregar toneladas de "std::"s para solucionarlo otro poquito más.

 

Todo lo demás

Finalmente, hay que hacer otras cosas como actualizar la ayuda de acuerdo a los cambios, actualizar la imagen de la splash-screen, completar el changelog, correr los antivirus (y rezar para que no salten falsos positivos), subir los archivos, actualizar en el sitio web (la lista de opciones de descarga, los números de versiones, los hashes de los nuevos archivos, agregar una noticia...), etc, etc, etc.

Sumando todo esto, la release está requiriéndome muchísimo tiempo. Y recuerden que esto consume de mi "tiempo libre". El trabajo en la Universidad (que es mi verdadero "trabajo") también se complicó últimamente, ni hablar del tiempo que se lleva la bebé, y que finalmente debo destinar otro poco de tiempo a otras cosas, como hacer deporte para no perder la cabeza. Así que por estos motivos la nueva versión viene muy muy demorada. Pero la buena noticia es que ya falta muy poquito, el 90% de lo que mencioné ya está hecho.