gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] CMake WIP


From: al davis
Subject: Re: [Gnucap-devel] CMake WIP
Date: Mon, 5 Aug 2013 19:16:31 -0400
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

On Monday 05 August 2013, Felix Salfelder wrote:
> > It could also be included in plugins, but isn't yet.
> 
> that will not be a problem. plugins will not be
> touched/recompiled if you checkout another gnucap branch.

Actually, it is.

The key is the header files.  Other changes are not a problem.

I update the version of gnucap installed, and have an old model 
plugin.  I load it and **crash**.

The reason for the crash might be a change in the header, 
perhaps something like a set of "noise" functions added to the 
devices.  That rearranges the vtable, so the function pointers 
don't match.

Probably most users will be using the stable versions, likely 
installed through deb or rpm, and plugins obtained separately.

Of the users not using deb, rpm, or whatever, most will be 
building from a release or snapshot tarball, not using git.  
That includes most creation of new plugins.

> > It could be used as a mechanism to check that a plugin is░
> > compatible with the executable that loads it ..  which I
> > have░ found is needed but is not done now.
> 
> this is really difficult outside linear (release) history.
> how about using the preprocessor to keep track of features?
> so you can always decide what to do, if that feature is not
> available.
> 
> for example
> #ifndef GNUCAP_THISANDTHAT
> #error "need this and that"
> #endif
> 
> but also
> #ifdef GNUCAP_SENS
> void MYMODULE::do_sens() { ... }
> #endif
> 
> this way you can also implement experimental features into
> stable plugins without breaking anything.

Please don't.  Keep the stable code clean.

Do as you want in plugins that are distributed separately or as 
unstable.

Mostly I consider #ifdef to mean "this file not ready for 
release".  There are exceptions to this.  One is to wrap headers 
to protect against multple inclusion.  At one time I tried to be 
strict here and prohibit multiple inclusion, but it didn't work.  
Another is that I use it to comment out blocks that are unused 
but being stored for future use while satisfying test scripts 
that would otherwise complain about untested code.






reply via email to

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