Los desafíos de portar PSeInt a macOS Catalina (3/3): Los últimos detalles

Ya conté los problemas y soluciones para poner en marcha un toolchain para las nuevas versiones de macOS, y la migración del código de wx 2 ansi a wx 3 unicode, en GNU/Linux. Solo me faltaba combinar todo esto para ver si andaba en macOS, si tenía un paquete para publicar en el sitio. Por supuesto que no anduvo a la primera. He aquí los últimos detalles de esta historia.


El problema de los dylibs

Una vez que pude compilar tanto wx, como los distintos módulos de PSeInt con el nuevo toolchain, armé un paquete con la estructura que le gusta a macOS y me dispuse a probarlo en una máquina virtual: no podía ni iniciar PSeInt porque los binarios de PSeInt no encontraban a los binarios de wxWidgets.

Los dylibs en mac son más o menos como los dlls en Windows, o como los .so en GNU/Linux. Antes, con IMCROSS, había compilado wx para enlazado estático. Esto es, para ponerlo dentro de cada ejecutable. El problema es que PSeInt en realidad está formado por varios ejecutables, y entonces esto hace al paquete final innecesariamente grande. Lo mejor en este caso es enlazado dinámico: que estén una sola vez, fuera de los ejecutable, y que todos ellos busquen esos mismos archivos.

En el paquete para mac, hay un directorio Contents, que adentro tenía dos directorios: MacOS y Resources. En MacOS está el ejecutable principal; en Resources todo los demás: los otros ejecutables, la ayuda, los íconos, etc. Ahora hay un tercero: Frameworks, donde está wxWidgets. El problema es que luego de compilar, me quedó en el ejecutable la ruta al binario de la biblioteca tal cual se la di al compilador. Esto es, la ruta donde yo los tengo en mi GNU/Linux. En la Mac esta ruta no existe ni tiene sentido. Las rutas deberían llevar a Frameworks, y ser relativas.

Después de googlear un rato, llego a que una herramienta otool me puede mostrar las rutas que tiene adentro cada binario, y otra herramienta install_names_tool me deja modificarlas. Entonces, desde un script de bash, uso la primera para encontrar las dependencias, y la segunda para corregirlas (recursivamente, también entre los propios archivos de la biblioteca). El detalle de color fue que en uno de los binario los paths nuevos no entraban y entonces tuve que dar con un argumento de compilación más para agregar un relleno a los paths, de modo que luego install_names_tool tenga espacio de sobra.


GNU/Linux vs. macOS

Una vez compilado, empaquetado, y ejecutándose, era hora de ver si la ejecución hacía lo que debía. Se supone que el objetivo de wx es independizarnos de la plataforma, que programemos contra wx y eso se compile y comporte igual en cualquier sistema operativo. No siempre funciona así al 100%, a veces varían sutilmente cosas como el orden de los eventos que reciben los controles, o el tipo de evento que generan ciertas acciones.

Antes no podía quejarme de esas diferencias por no usar el wx que corresponde, ahora puedo! Pero igual, hasta que se resuelvan, tengo que identificarlas yo y aplicar algún parche a mi código. Me pasó algo de esto con el editor de diagramas de flujo. La forma de detectar las teclas me funcionaba perfectamente en GNU/Linux, pero no en macOS.

Los detalles de este tipo que eran funcionales fueron corregidos. Algunos llevaron mucha prueba y error. Los que son estéticos todavía no, esos tienen por el momento baja prioridad. Por ejemplo, si usan un tema de fondo oscuro en macOS, algunos elementos de la interfaz se ven "feos". Feos pero andan que es lo más importante. La estética se irá arreglando luego de a poco.


Otras, varios y miscelánea

Finalmente, ahora que PSeInt funciona con wx 3 unicode, no solo tengo una versión para los usuarios de macOS Catalina. Sino que también de a poco me voy despegando de un compilador y una biblioteca muy viejos. Un compilador más nuevo me permite migrar a C++11 o C++14 y limpiar mucho el código. Y una biblioteca más nueva agrega funcionalidad. Por ejemplo, ahora scintilla ofrece annotations, que puedo usar para mostrar los errores de una forma algo mejor que la anterior.

Comparación entre mostrar los errores como annotations (arriba, wx3), o mediante tooltips (abajo, wx2).

Por otro lado, usar otro compilador distinto al habitual y más nuevo hizo que aparecieran muchos warnings. Algunos me sirvieron para corregir pequeños errores, otros tuve que silenciarlos o dejarlos para más adelante. Pero en cualquier caso, más información de diagnóstico siempre es buena noticia.


Toda esta experiencia me servirá cuando intente migrar ZinjaI a wx3. ZinjaI puede sacarle mucho más jugo a las nuevas funcionalidades de wxWidgets, pero también es mucho más difícil de portar. Es mucho más grande, y hay mucha más interacción entre la interfaz y todo tipo de cosas ajenas (el compilador, el depurador, el parser, el diseñador, los profilers, el sistema de archivos, mis propias clase, etc). Por eso llevará mucho más tiempo, pero que PSeInt ya funcione es una muy buena señal.