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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
