This is not the case.
libavogadro and avogadro don’t “link” to tools / engines as they are
plugins. what they do link to is tool.o (the template class). Now, if
someone upgrades libavogadro, old avogadro app DOES link to the new
libavogadro you are correct. but libavogadro is what’s loading the
Also, consider the case where avogadro-app manually loads it’s own
plugins directly (your libsometool.so). The loading of plugins is based
off the tool.h header file which is under ABI lock. But nothing is
linking / using any of the header files from the tools/engines
I believe one good way to know if something is under ABI freeze: is it
available through a public header?
Also consider if you change an engine and then recompile. No matter if
you add a new function or whatever, libavogadro does not get recompiled.
Why? Because the interface to the plugins hasn’t changed even though the
I mean, think about it this way, what if i’m a 3rd party and i want to
create a plugin (crazy) for libavogadro installed on my system. All i
have is the tool.h file and libavogadro.so which i link against my
plugin (libcrazytool.so). Now when libavogadro / avogadro runs and
loads this plugin, it has no prior notion of what the layout of the
plugin. It also has no idea about crazy.h, it’s header file. All it
has is the libcrazytool.so file. But! Alas they do both have something
in common; tool.h Both libavogadro and libcrazytool are based on a
single header file layout that is under ABI constraints.
PS: Avogadro (at this point) doesn’t load any tools / engines directly.
It does load it’s own extensions. But applications like Kalzium may
choose to load their own tools / engines.
(Fri, May 04, 2007 at 11:13:50AM +0200) Benoît Jacob firstname.lastname@example.org:
something just occured to me while chatting with Marcus. The tools and engines
in libavogadro are subject to the same ABI compatibility requirements as
libavogadro itself, aren’t they? This boils down to the question: will apps
link directly to libsometool.so, or will they only link to libavogadro.so and
let libavogadro.so link to libsometool.so ? I think they will link directly,
won’t they? At least in Avogadro I see code manually loading plugins one by
one, so I guess Avogadro links directly.
That means that the engines/ and tools/ subdirectories of libavogadro/src/
must undergo the same d-pointer-ification that we have done in
Below is a IRC log:
[11:03] imagine a user has avogadro and libavogadro installed
[11:03] then he upgrades libavogadro
[11:03] by the way he upgrades the tools that come with libavogadro
[11:04] the old avogadro app now links to the new tools !
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Avogadro-devel mailing list