On Tuesday June 1 2010 13:39:47 Kent Andre wrote: > On Tue, 2010-06-01 at 10:59 -0700, Johan Hake wrote: > > On Tuesday June 1 2010 10:32:43 kent-...@simula.no wrote: > > > > On Saturday May 29 2010 03:05:42 kent-...@simula.no 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 > > > > > > The shared library from the cache would not load. This shared library > > > was linked > > > against another dolfin of the same version, but compiled/linked in > > > another way. I > > > don't think it had to do with the -O2 or similar options, but rather > > > that it was > > > linked against another set of libraries (Trilinos, PETSc, etc.). Some > > > of these are e.g. not in LD_LIBRARY_PATH for the dolfin in use. > > > > Ok. I think this gets too complicated to fix at the module signature > > level. > > > > I would suggest you to use different INSTANT_CACHE_DIR variables for the > > different DOLFIN builds. > > > > Johan > > I can use the INSTANT_CACHE_DIR variable, sure :) > > But, it should not be to hard to do. In instant it is easy to > add compiler/linker options to the signature. One option is > use both the .i file and the setup file to generate the checksum. > > Similar can be done in dolfin. Or to speed up the process, a > dolfin library specific signature could be generated during > compilation.
I agree that this is possible, and I agree that it would be nice! The _only_ thing we need is to find the library binary which we link to during JIT compiling and add a hash sum of that file to the signature. If you have a fool proof, portable and short way of finding the binary, please feel free to share it! Johan > This would probably get rid of some of the 'instant-clean's that > mysteriously remove troubles. > > Kent _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
