Re: [OT?] Desarrollo aplicaciones multiplataforma (casi filosofia. Un poco largo)
Ipsissima verba Armando Paz:
> Y AQUI ENTRONCO CON OTRA DUDA: en linux yo le pasaría mi script a
> cualquier compañero y todo el mundo podría ejecutarlo porque
> habitualmente tanto PERL como PYTHON ya están instalados... pero en
> Windows, para los colegas que usen eso, tendrían que instalarse
> previamente el intérprete, y supongo que también las librerías
> gráficas etc. EN RESUMEN: si utilizara un lenguaje compilado podría
> obtener un "ejecutable autocontenido" que podría grabar en un
> disquete y pasárselo a cuantas personas quisiera, creo que esto no
> es posible con un lenguaje interpretado, ¿verdad?
Bueno, puedes incluir el intérprete junto con tu paquete... es una
solución poco elegante... oh, bueno, es una solución *espantosa*, pero
los muchachos de Visual Basic lo hacen a cada rato ¿no?
Ya en serio, por ahí te indican que hay un compilador de Perl. GCC
tiene también un compilador de Java, creo. No sé qué tan maduras y
estables sean esas herramientas (a juzgar por lo poco que he oido de
ellas no deben ser muy sólidas aún).
> CONCLUSIÓN: si me decido por un lenguaje interpretado, al existir
> intérprete para LINUX y para WINDOWS mi "programa" sería plenamente
> multisistema operativo pero exigiría una dificultad de "instalación"
> porque el programa no es suficiente por si solo sino que necesita un
> intérprete instalado y, SUPONGO que si quiero obtener salida gráfica,
> también librerías gráficas instaladas. Y TODO ESTO FUNCIONANDO
> CONJUNTAMENTE--->ESFUERZO DE CONFIGURACIÓN ADICIONAL DE CADA UNA DE
> LAS PARTES.
Eso es correcto. Y sí, es un problema real en ese sistema operativo que
mencionas. E incluso en Linux; considera, por ejemplo, lo difícil que
es poner BitTorrent en Debian Woody: no hay una versión empacada, y no
es fácil que simplemente bajes el "tarball" y lo instales en /usr/local
porque depende de versiones de Python, wxWindows y el binding entre
ambos, que tampoco están empacadas...
(O no estaban, al menos, la última vez que intenté usar BT en woody.
Y este es un caso excepcional, y la inconveniencia es temporal... pero
creo que ilustra el problema.)
Adicionalmente, el hecho de que Perl o Python sean portables no implica
que, por ejemplo, la combinación Perl+GTK+Glade también lo sea.
> Si algún día fuera capaz de "desarrollar" algo medianamente interesante
> para que fuera un paquete Debian lo de la instalación de "mi
> programa=paquete" estaría resuelto por las dependencias: mi paquete
> dependería de PERL o PYTHON, de la librería gráfica y otras cuantas
> cosas más... y un fácil apt-get acabaría instalando todo lo necesario.
> Pero, que haría para pasárselo a los amigos de Windows ¿hay forma de
> crear un paquete con todo lo necesario? ¿y en ese paquete que tendría
> que meter: todo el ACTIVEPERL - por ejemplo -, toda la librería
> gráfica...?
¡Hey! ¡Era broma solamente, no lo decía en serio!
:-)
Seguramente se puede. Probablemente tu pequeño manejador de contactos
acabe siendo un download de veinte megas (y requiriendo cuarenta megas
de RAM, si usas Java). Posiblemente tengas que crear un instalador
sofisticado, o comprar uno.
Yo también considero muy deseable hacer ejecutables "autocontenidos", o
al menos sólo con dependencias razonables. Mi criterio: en Linux, GTK+
o Qt son dependencias razonables; en Windows, msvcrt.dll et al son
dependencias razonables. Casi cualquier otra cosa sólo es razonable,
como bien dices, en un sistema como Debian, capaz de resolver
dependencias automáticamente.
Pero estoy divagando. Mira, te haré una recomendación concreta:
En tu caso yo reharía el programa en C++, sobre wxWindows. Para Win32
generaría binarios con wxWindows enlazada estáticamente---eso agrega
como 2MB al tamaño de los ejecutables, pero evita tener que cargar con
DLLs. Para Linux generaría versiones dinámicas instalables como
paquetes deb (y le encargaría a alguien hacer RPMs).
Un "plus" que quizá te haga más atractiva la recomendación: si
instalas un cross-compiler (mingw-msvc), puedes generar *en tu Debian*
una versión de wxWindows para Win32. Y con ella puedes generar
binarios ".exe", y solo copiarlos a la máquina en donde van a correr.
Y eso no es un "creo que se puede" de mi parte. Estoy *seguro* de que
se puede. Lo hago todo el tiempo.
-CR
Reply to: