[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On April 12, 2010, Matthew Leverton wrote:
> On Mon, Apr 12, 2010 at 1:38 AM, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>
wrote:
> > what I'm assuming you propose:
> >
> > acodec.dll:
> > int init_acodec() { init_flac(); init_blah(); ... }
>
> Nothing is initialized until used. If you don't use FLAC it never
> tries to load the DLL. This is obviously an *improvement* over
> standard linking. Allegro currently has to get around that annoyance
> by putting everything in its own DLL. (allegro_flac).
>
> The only down side to my proposal, that I can see, is that if you
> *choose* to create a monolithic library with standard "build time"
> links, you'll have to distribute every codec DLL. But, in my opinion,
> that's just a contrived case that nobody seriously would ever want to
> do.
>
> > int init_flac() {
> > dlopen("libFLAC.so");
> > // load a crap load of flac functions into function pointers here
> > }
>
> Basically yes, except "crap load" is only ~10 per module. And it's
> done conditionally... if the library wasn't found at compile time.
>
> It's all in the diff, do a search for "libdumb_dll" in particular.
You can hide your loading in the extra plugin libs too as well. I suppose
the only real downside to your solution is that adding more codecs would
mean a new version of allegro, rather than a simple copy of a new loadable
plugin.
> --
> Matthew Leverton
>
> -------------------------------------------------------------------------
> ----- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx