Re: plugin plans

Felix Salfelder <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
On Thu, Feb 19, 2015 at 03:09:09PM -0500, al davis wrote:
> Perhaps we should explicitly make our own path.

i don't like this. lets not reinvent the wheel.

> -------which one?

the second one, the symbol.

> > will not allow to load forcefully. otherwise i
> > really like it, it should be added as a safety net between
> > major versions/revisions.
> 
> Actually, the second does allow to load forcefully with the 
> "lazy" option already there.  Perhaps it should be called 
> "force" instead.

right, i should have read the manual. so this symbol idea is even
better, perfect.

> To decide whether forced load makes sense we need to ask why a 
> mismatch matters.

> The answer is that the headers might not match, making some 
> addresses resolve to being different in plugin vs. core.  It 
> this case, it is likely to cause a crash so forcing it would not 
> be a good idea.

we shold have an interface version number for releases (i vaguely
remember a number, about 138 from patchlev.h...?) and call it interface
version. anything more standard [1] will likely be too complex for our
needs. i think this interface version is a good candidate for a symbol
name. increments must be done manually, upon header change.

why force/lazy? for development. i think during development the
interface version symbol should be replaced or accompanied by some sort
of git tag/description/commit-id. just to avoid shooting into feet.
then, lazy will come in handy for the developer who knows what (s)he is
doing.

cheers
felix

[1] http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.