ABI stability in libavogadro tools and engines

Hi List

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
libavogadro/src/.

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 !

Cheers,
Benoit

Many thanks Donald for this long explanation.

I am embarassed because, if I understand well, that means Marcus’s work
d-pointerifying the NavigateTool was not needed. Sorry Marcus!

Thus the only classes that we need to d-pointerify are those in the
libavogadro/src/ directory, not those in subdirectories. Right?

I think there remain some classes to d-pointerify. At least Sphere. Will
do it unless someone does it before me.

Cheers
Benoit

On Fri, 4 May 2007, Donald Ephraim Curtis wrote:

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
engines/tools.

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
subdirectories.

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
plugin has.

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 jacob@math.jussieu.fr:

Hi List

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
libavogadro/src/.

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 !

Cheers,
Benoit


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.
http://sourceforge.net/powerbar/db2/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On May 4, 2007, at 11:19 AM, Donald Ephraim Curtis wrote:

I believe one good way to know if something is under ABI freeze: is it
available through a public header?

Better yet, the public headers establish a particular API/ABI version
for the plugins:

Q_DECLARE_INTERFACE(Avogadro::ToolFactory,
“net.sourceforge.avogadro.toolfactory/1.0”);

So this is version 1.0 of the ToolFactory interface. Let’s say in the
future, we add new features to the render engine interface and call
it 2.0. (I dunno, it handles 4D space-time rendering with special
glasses.)

Now imagine I send one of these cool updated engines to my friend who
has an older version of Avogadro or Kalzium. Qt will refuse to load
the new engine plugin because the interface versions don’t match.

In short, plugins are the way to go – we can expand the
functionality of the program without causing all sorts of library
breakage. Just wait until we add scripting extensions. :slight_smile:

Cheers,
-Geoff

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
engines/tools.

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
subdirectories.

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
plugin has.

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 jacob@math.jussieu.fr:

Hi List

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
libavogadro/src/.

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 !

Cheers,
Benoit


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.
http://sourceforge.net/powerbar/db2/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel