[ 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