gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] CMake WIP


From: Felix Salfelder
Subject: Re: [Gnucap-devel] CMake WIP
Date: Mon, 5 Aug 2013 18:30:32 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Aug 05, 2013 at 11:56:44AM -0400, al davis wrote:
> On Monday 05 August 2013, Felix Salfelder wrote:
> > patchlev.h is included in 4 .cc files. recompilation/linking
> > takes about 10 seconds. thats much better than a wrong
> > version string, if you want to rely on it.
>
> 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.

> 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.

> Since this is an internal matter, I think a simple code would be░
> better than that whole string ....  perhaps the RCS number (no░
> longer maintained) or the GIT tag, or something else.

i think releases should still be numbered. so a plugin can easily check
whether VERSION >= X. i'm not so sure in which way this is practical.

but in any case, the output of "git describe" should be included into
patchlev.h somehow...

> The RCS number is probably the best way, except that we don't░
> have it anymore unless it is manually updated.  The git tag is a░
> random string, which doesn't lend itself to comparisons like░
> "later than", but it might be the best way.

a git tag should always contain the release number, so it's not too
random.

regards
felix



reply via email to

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