¿plugins en plataformas que no soportan carga dinamica de librerias?

[efegea]

Soy un fanático de añadir sistemas de plugins a mis proyectos, como el media center o el motor 3D. Pensad lo que querais pero progamar algo con soporte de plugins me pone cachondo :lol:

Bueno, a lo que iba.

Normalmente un plugin consiste en una librería de enlace dinámico (.dll, .so) que se carga dinámicamente durante la ejecución del programa.

Hasta ahora todo bien, pero ¿que hacer cuando una determinada plataforma no soporta librerías de enlace dinámico? Como por ejemplo una consola (descartamos GP2X al llevar ésta linux que SI los soporta)

¿Alguién sabe como solventar este problema? Algunos diréis, ¿y porqué no los enlazas estáticamente? En ese caso no podría "descubrir" qué plugins hay y pedirles que se autoregistren en la aplicación. Es decir, en mi código actual del media center, el pluginManager mira todos los plugins que hay en un directorio y los carga, acto seguido les pide información y los registra. Esto no lo podría hacer si lo hubiese compilado estáticamente, ¿sabéis si es posible de otra forma?


Espero haberme explicado bien >_<

[neglox]

Existen aplicaciones que utilizan plugins interpretados (por llamarlo de alguna forma), me explico:

Nuestro programa tiene un plugin manager que es un int&#233;rprete.
Los plugins son en realidad c&#243;digo que ha de ser interpretado y convertido por el interprete en c&#243;digo m&#225;quina.

Ventajas? Multiplataforma total y soluciona tu problema.
Desventajas? Costoso de implementar (Crear todo un int&#233;rprete) ,bastante m&#225;s lento.

[Propeller]

Soluci&#243;n: Plugins en python, perl o lo que sea.

Propeller

[efegea]

Ah por cierto, lo que estoy haciendo ahora mismo es hardcodearlo todo, por lo que de plugins no tiene nada. Lo que quiero hacer es que se pueda usar tanto din&#225;mica como est&#225;ticamente.

Lo que hago ahora con el motor 3d es, en el caso de los plugins que son varios del mismo tipo (cargadores de modelos p.ej, un plugin para MD2, otro para MD3, otro para CAL3D, etc) los hardcodeo en el xxxManager (donde xxx puede ser scene,material,etc) asi:


m_meshLoaders[m_numMeshLoaders]=new CMeshLoaderMD2();
m_numMeshLoaders++;
m_meshLoaders[m_numMeshLoaders]=new CMeshLoaderCAL3D();
m_numMeshLoaders++;

donde cada CMeshLoaderXXX es una clase derivada de IMeshLoader, de la cual m_meshLoaders[] es tambi&#233;n de ese tipo. Ahora, cuando va a cargar un modelo pregunta a todos los meshLoaders que haya si ese modelo (el nombre de archivo) se puede cargar, si es que s&#237;, usa ese "plugin".

Pero claro no me parece buena idea hardcodearlo...

Para los plugins que s&#243;lo puede haber una instancia de cada tipo (s&#243;lo un driver de render, s&#243;lo un driver de audio, solo un driver de entrada...) lo que hago es que como cada implementaci&#243;n de, por ejemplo, cada driver de entrada, est&#225; en un archivo .cpp diferente, pues en el Makefile de tal plataforma pongo s&#243;lo ese archivo y no los de las otras plataformas. En ese archivo hay una funci&#243;n getDriverInput(), que es a la que llama el nucleo del motor para obtener el driver, o "plugin".

[efegea]

Solución: Plugins en python, perl o lo que sea.

Propeller

No puede ser, tiene que ser en C++ :(

[Jurk]

y si haces el plugin estatico?:confused:

O creas un compilador que compile los plugins que encuenterre...

(no tengo mucha idea, pero...)