Re: [AD] alsamidi fix

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Elias Pschernig wrote:

On Wed, 2004-07-21 at 06:31 -0700, Chris wrote:
Elias Pschernig wrote:
I already suggested once to change this behavior, and have a version
compiled with --disable-modules never use any modules at all, not just
not compiled them. Maybe we should reconsider this.
What are the advantages modules have that isn't already provided by compiling as a shared lib? As we see here, it's dangerous to mix module and library versions. What was the original reason for seperating them into modules?


It's only dangerous in unstable branches.

No, just the behavior of --disable-modules is unclear. I'd expect it to
build a lib with modules disabled, not to just disable building of
modules.

That was my intention, actually :-)

I'd be all for merging it all back into the main lib, unless there's a reason not to.

Are you proposing to drop modules support? I think they are needed for
binary distributions. Peter or Eric will be able to tell you more. And
this is actually something else I must added to the wiki, once I have an
answer :)

Yes, binary distributions is the answer. Modules can have dependencies on other shared objects that we don't want liballeg.so to have. Packagers can then build a binary package of Allegro that supports a bunch of optional libraries, without requiring the user to install all the optional libraries as prerequisites.

Run ldd on liballeg.so.4.x, and you'll see it only depends on a few standard libraries. The only odd one out is X, because it was too hard for me to separate out X support into a module in time for 4.0.0. Luckily pretty much everyone installs X anyway so, practically speaking, it'd be a waste of time.

There was a different reason for having alleg-vga.so (it has no dependencies, after all), but I've forgotten. Eric?

Peter





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/