[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
Re: [Gnucap-devel] plugin plans, al davis, 2015/02/13