Free Pascal y Lazarus estrenan paquetes dinámicos

¿Qué pasó con Free Pascal y Lazarus?

Free Pascal y el IDE Lazarus ya cuentan con la primera versión de soporte completo para paquetes dinámicos (dynamic packages), disponible para descargar según el anuncio publicado en getlazarus.org. La consecuencia práctica es concreta: al compilar un paquete abierto, sus controles, componentes y extensiones asociados se actualizan dentro del IDE en uno o dos segundos. Antes, ese mismo cambio exigía reconstruir el IDE completo.

Para un equipo que mantiene productos de escritorio en Object Pascal —sistemas de punto de venta, herramientas internas de gestión, software industrial— eso convierte un ciclo de minutos en una iteración casi instantánea.

¿Qué son los paquetes dinámicos y qué habilitan?

Los paquetes dinámicos se implementan como archivos de librería compartida estándar para Linux, Windows y macOS. Además del código, contienen metadatos extra generados por el compilador que se pueden inspeccionar y consultar con nuevas unidades de la RTL (la librería de runtime).

El objetivo no es solo acelerar el IDE. Los paquetes también se pueden usar dentro de tus propios programas para desarrollar y desplegar plugins que exponen clases y tipos nativos de Pascal a través de librerías de paquetes dinámicos. Al distribuir, puedes seguir empaquetando todo en un único ejecutable o dividir la aplicación en varios paquetes que se reemplazan con el programa en ejecución: eso es, literalmente, un sistema de plugins.

Un detalle técnico explica buena parte de la dificultad del proyecto: el runtime incluye mecanismos para preservar de forma segura las variables de hilo (thread variables) y para gestionar tipos dinámicos como strings y arrays dinámicos entre un programa y sus paquetes, o entre varios paquetes entre sí. Sin ese trabajo, mover datos a través de las fronteras del módulo sería una fuente permanente de corrupción de memoria.

Para trabajar con todo esto se agregó a la RTL la unidad DynPkgTypes.pas. Su registro TPackageType expone el nombre de la unidad que declara el tipo, el nombre del tipo, su clase (TTypeKind), su información RTTI (PTypeInfo) y la clase asociada cuando el tipo es una clase. Con esas funciones se pueden cargar, enumerar, buscar y liberar paquetes en tiempo de ejecución.

Por qué esta pieza tardó tanto en llegar

La wiki del proyecto Free Pascal documenta que el término paquetes siempre fue ambiguo dentro del ecosistema: puede referirse a unidades de FPC que se instalan en conjunto, a paquetes de Lazarus que se registran en el IDE, o a un conjunto de unidades compiladas en una DLL con características extra que la vuelven parte lógica del programa principal. A esta última variante —herencia directa de Delphi— la propia wiki la describe como una de las piezas que faltaban para la compatibilidad con Delphi.

La razón de la demora está en la palabra transparente. Según esa misma documentación, lo que separa a un paquete de una librería dinámica común es que existe una sola instancia del estado de cada unidad: un único conjunto de estado de la RTL y la FCL, de resourcestrings, de inicialización y finalización de unidades, de manejo de excepciones y de tablas VMT. La wiki resume la diferencia en dos palabras: los paquetes son automáticos y seguros, mientras que el enlace dinámico tradicional es un enlace a ciegas contra un encabezado que puede o no coincidir.

Esa misma página advierte dos límites que siguen vigentes y que conviene tener presentes: el esquema no resuelve el versionado de las librerías, y no sirve de nada si todas las partes no están compiladas con la misma versión de FPC.

Vale recordar el punto de partida del ecosistema: cuando Lazarus llegó a su versión 1.0 en 2012, tras más de una década de desarrollo, el medio I Programmer lo describía como un proyecto de nicho pero con una comunidad entusiasta, y ubicaba a Object Pascal y Delphi en el puesto 11 del ranking TIOBE de comienzos de ese año.

Las restricciones que debes conocer antes de adoptarlos

El anuncio lista tres límites concretos:

• Una unidad no puede llamarse igual que el paquete que la contiene. Para evitar el problema, el sistema agrega automáticamente la palabra Package al nombre del archivo fuente generado: si creas un paquete llamado ElectroTools.lpk, el archivo que lista sus unidades será ElectroToolsPackage.pas y no ElectroTools.pas.
• Los nombres de unidad deben ser únicos entre paquetes. Si alguien más escribió una unidad llamada Widgets, no puedes instalar otro paquete con una unidad del mismo nombre: tendrás que elegir qué paquete instalar o renombrar una de las unidades en conflicto.
• Los paquetes dinámicos pesan más que una librería compartida normal, porque contienen un mapa de todo lo que llevan dentro. Si aplicas strip a un paquete dinámico, eliminas los metadatos que necesita para funcionar como tal.

¿Qué cambia dentro del IDE de Lazarus?

El anuncio detalla varias mejoras pensadas para aprovechar los paquetes dinámicos:

• Ventana de progreso. Al modificar el código de un paquete registrado, el sistema detecta el cambio y reconstruye el paquete antes de que Lazarus arranque, con una ventana que informa lo que está pasando. La misma ventana aparece al reconstruir el IDE completo y muestra el tiempo estimado antes del reinicio; también se activa al agregar o quitar paquetes si la operación pasa de cinco segundos, algo posible al instalar varios paquetes a la vez, otra función nueva.
• Ventana de Paquetes, anclada a la derecha por defecto, con la lista de los paquetes abiertos recientemente —la lista persiste entre sesiones—, donde puedes explorar los archivos de un paquete y abrir cualquiera con doble clic.
• Menú de paquetes mejorado: agregar o quitar paquetes ahora actualiza el IDE sin necesidad de reconstruirlo.
• Opciones por plataforma. En IDE Integrations puedes restringir un paquete a una plataforma o widgetset específico. Si no cumple los requisitos actuales, no aparece en la lista y el IDE lo ignora al detectar cambios. El ejemplo del anuncio: una implementación TWinControl para la interfaz COM IShellView de Windows puede restringirse para que solo esté disponible cuando Lazarus corre sobre Windows.
• Conversión de formularios y frames en controles instalables, que se agregan automáticamente a la paleta de componentes copiando controles, eventos, métodos y propiedades. Sirve para diseñar visualmente un control nuevo o reutilizar formularios y frames existentes en otros proyectos.

Una advertencia operativa del propio anuncio: si intentas compilar un paquete que está en uso por un formulario abierto, el IDE te pedirá guardar o cerrar el formulario primero.

¿Qué significa esto para tu startup?

1. Prototipa un plugin interno antes de rediseñar nada. Si mantienes una herramienta interna en Pascal que se actualiza por versiones completas, elige un módulo acotado y expórtalo como paquete dinámico usando DynPkgTypes.pas. El objetivo es medir cuánto se acorta tu ciclo de despliegue, no reescribir la arquitectura.

2. Audita colisiones de nombres antes de escalar. La unicidad de nombres de unidad es la regla que más rompe instalaciones cuando varias personas publican paquetes en el mismo entorno. Revisa el prefijo de tus unidades ahora, mientras el catálogo interno todavía es chico.

3. Fija versiones y no lo lleves todavía a tu build de producción. Los cambios completos de FPC y Lazarus se comprometieron a GitLab en una rama bifurcada llamada dynamic packages: es una implementación en fork, no una versión estable del proyecto upstream. Y la wiki del proyecto advierte que el esquema no funciona si todas las partes no comparten la misma versión de FPC. Para producción, congela la versión del compilador.

4. Si vendes componentes, revisa la licencia. La wiki del proyecto señala que distribuir componentes solo en binario enlazados contra código GPL no es viable por licencia, ni siquiera con enlace dinámico. Es un punto a validar antes de armar un modelo de negocio alrededor de paquetes cerrados.

Lo que el proyecto todavía necesita

El autor, que firma como sysrpl, pide dos cosas concretas: moderadores para el sitio y un Mac con chip M1 donado, porque tiene dificultades para producir los builds de macOS y quiere trabajar en el código que hace falta para soportar paquetes dinámicos en esa arquitectura. Los problemas se reportan en el rastreador de issues de GitLab asociado a las ramas mencionadas, y el foro exige que un moderador apruebe la cuenta antes de poder publicar.

Si tu equipo usa Lazarus en producción, ese pedido es una vía de bajo costo para influir en el roadmap de la plataforma.

Conclusión

Los paquetes dinámicos cierran una de las brechas históricas frente a Delphi: componentes instalables sin reconstruir el IDE y plugins reales para aplicaciones Pascal. El ahorro es tangible —un cambio que antes obligaba a recompilar todo hoy se refleja en uno o dos segundos—, pero conviene tratarlo como tecnología en consolidación: vive en una rama fork, arrastra restricciones de nombres y de tamaño, y mantiene pendiente el problema de versionado que la wiki del proyecto señala desde hace años. La jugada sensata para un founder es experimentar ahora en un módulo interno y esperar la integración upstream antes de tocar el build de producción.

Fuentes

• Dynamic Packages — getlazarus.org (fuente original)
• packages — wiki del proyecto Free Pascal
• Pascal IDE Lazarus 1.0 Released — I Programmer