gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] plugin plans


From: Felix Salfelder
Subject: Re: [Gnucap-devel] plugin plans
Date: Thu, 19 Feb 2015 22:09:24 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]