dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #18460
Re: JIT compiling in Dolfin
On Saturday May 29 2010 03:05:42 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.
> >
> > --
> > Anders
>
> 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.
What exactly was the problem? Was it binary incompatability of two different
libdolfin from the development build? We have not exposed the compilerflags to
dolfin extension modules. By default they are compiled using -O2. Or was it
the compilerflags for libdolfin that caused the problem, and if so, how could
that be?
Johan
> Kent
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help : https://help.launchpad.net/ListHelp
Follow ups
References