← Back to team overview

dolfin team mailing list archive

Re: JIT compiling in Dolfin

 

On Tue, Jun 01, 2010 at 11:17:45AM -0700, Johan Hake wrote:
> On Tuesday June 1 2010 11:12:41 Anders Logg wrote:
> > On Tue, Jun 01, 2010 at 11:00:22AM -0700, Johan Hake wrote:
> > > On Tuesday June 1 2010 04:03:33 Anders Logg wrote:
> > > > On Sat, May 29, 2010 at 12:05:42PM +0200, kent-and@xxxxxxxxx wrote:
> > > > > > On Fri, May 28, 2010 at 09:01:22AM -0700, Johan Hake wrote:
> > > > > >> On Thursday May 27 2010 23:28:19 Kent Andre wrote:
> > > > > >> > On Thu, 2010-05-27 at 18:52 -0700, Johan Hake wrote:
> > > > > >> > > You can controll this by setting the environment variable:
> > > > > >> > >   INSTANT_CACHE_DIR
> > > > > >> > >
> > > > > >> > > to different directories for the different DOLFIN builds.
> > > > > >> > >
> > > > > >> > > If you use different conf files for the different DOLFIN
> > > > > >> > > builds you
> > > > > >>
> > > > > >> can
> > > > > >>
> > > > > >> > > easily controll the instant cache dir from within these.
> > > > > >> > >
> > > > > >> > > We once included the dolfin version in the cache id, but it
> > > > > >> > > was
> > > > > >>
> > > > > >> removed
> > > > > >>
> > > > > >> > > as it the ufc python module is not dependent on anything in
> > > > > >> > > dolfin.
> > > > > >>
> > > > > >> Not
> > > > > >>
> > > > > >> > > sure how true this is in reality though.
> > > > > >> > >
> > > > > >> > > What kind of troubles have you encountered?
> > > > > >> > >
> > > > > >> > > Johan
> > > > > >> >
> > > > > >> > The shared library in the cache is linked against another Dolfin
> > > > > >> > and therefore it wouldn't load.
> > > > > >>
> > > > > >> Ok I see. We are including the __version__ in the signature of the
> > > > > >> instant
> > > > > >> module, but if you are using the latest stable version together
> > > > > >> with a development version, you get the same version number,
> > > > > >> which wont trigger a new
> > > > > >> module.
> > > > > >>
> > > > > >> One way to fix this is to increase the version on all development
> > > > > >> versions.
> > > > > >> This would make sense as we are no longer developing the 0.9.7,
> > > > > >> which is released. We are developing 0.9.8, which is then
> > > > > >> reflected by the __version__
> > > > > >> string. Other softwares use this convention too.
> > > > > >>
> > > > > >> If we want to be water proof we could look up libdolfin.so and
> > > > > >> take a md5 sum
> > > > > >> of the file and use that in the signature. We then need to use
> > > > > >> different suffixes and prefixes for the different platforms.
> > > > > >
> > > > > > We should set the number to "x.y.z+" right after the release.
> > > > > >
> > > > > > This is done in FFC (as part of the post-release hook) and it needs
> > > > > > to be done also in DOLFIN. I'll add this to the DOLFIN
> > > > > > post-release hook.
> > > > >
> > > > > I think we should go for the water proof solution and use info either
> > > > > from the library or compiler options + version numbers. The compiler
> > > > > options solution might be the simplest portable solution (?).
> > > > > It should be simple enough to do.
> > > > >
> > > > > Kent
> > > >
> > > > The version number in DOLFIN is now set to 0.9.7+ and the release
> > > > script has been updated to take care of this for subsequent releases.
> > >
> > > Nice.
> > >
> > > Why not just step the dot release counter a whole step?
> >
> > You mean to 0.9.8?
>
> Yes.
>
> > That would be wrong since it is likely different from what 0.9.8 be.
>
> Sure, but it is becomming 0.9.8! It might be easier than introducing the "+".
> The users of the development branch would know that it is _not_ the final
> release, and it will distinct the development branch from the last stable one.
>
> But this is _not_ a big deal for me :)

I think the version number should indicate that it is not the actual
0.9.8. Another reason for calling it 0.9.7+ (and not something like
0.9.8-alpha) is that we don't know what the next version number will
be when making a release. I might get bumped to 1.0. (But not in this
case. I expect a 0.9.8 release soon.)

--
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References