Add dolfin version to JIT hash

[blechta]

This is a backport of DOLFIN old commit 1211d17cbf1d35727a57b01c61127bc904becaf1
where it fixed problems on Bamboo.

[garth-wells]

Is this needed? The generated code in FFCX does not include any DOLFIN code.

[blechta]

This is expression JIT and cpp code JIT, not FFC jit. So it depends on DOLFIN.

I'm not saying this is the best solution. Possibly one should hash all the inputs to jit_generate, including parameters which are telling how to link to DOLFIN. This was just a quick fix how to make a module rebuild when libdolfin.so.2018.1 changed into libdolfin.so.2018.2, see http://magpie.bpi.cam.ac.uk:8085/browse/DOL-DODO-PUTPY3-802.

[chrisrichardson]

Looks fine to me. Anyway, harmless.

[garth-wells]

I don't agree about harmless. I don't believe it is necessary, but will lead to the future 'this must be needed, but I don't know why'. Let's keep it simple.

[blechta]

I don't know how this should be handled corretly but consider this:

$DIJITSO_CACHE_DIR=$PWD python3 -c"from dolfin import *; Expression('x[0]', degree=1)"
$cat log/dolfin_expression_125be1689a7363df9e7605a8411cb0e9.txt
c++ -Wall -shared -fPIC -std=c++11 -O3 -fno-math-errno -fno-trapping-math -ffinite-math-only -I/usr/include/mpich -I/home/jan/dev/fenics-x/include/eigen3 -I/home/jan/dev/fenics-master/src/ffcx/ffc/backends/ufc -I/home/jan/dev/fenics-x/cachex/dijitso/include dolfin_expression_125be1689a7363df9e7605a8411cb0e9.cpp -L/home/jan/dev/petsc/local.master/lib -L/home/jan/dev/slepc/local.master/lib -L/home/jan/dev/fenics-master/src/dolfinx/local.master/lib -L/home/jan/dev/fenics-x/cachex/dijitso/lib -Wl,-rpath,/home/jan/dev/fenics-x/cachex/dijitso/lib -lmpich -lmpichcxx -lpetsc -lslepc -lm -ldl -lhdf5 -lboost_timer -ldolfin -olibdijitso-dolfin_expression_125be1689a7363df9e7605a8411cb0e9.so
$ ldd lib/libdijitso-dolfin_expression_125be1689a7363df9e7605a8411cb0e9.so 
	linux-vdso.so.1 (0x00007ffd7a735000)
	libdolfin.so.2018.2 => /home/jan/dev/fenics-master/src/dolfinx/local.master/lib/libdolfin.so.2018.2 (0x00007f68477ae000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6847420000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6847208000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6846e17000)
	libboost_timer.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_timer.so.1.65.1 (0x00007f6846c11000)
	libboost_filesystem.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 (0x00007f68469f7000)
	libboost_program_options.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1 (0x00007f6846776000)
	libhdf5.so.10 => /home/jan/dev/petsc/local.master/lib/libhdf5.so.10 (0x00007f68462aa000)
	libparmetis.so => /home/jan/dev/petsc/local.master/lib/libparmetis.so (0x00007f684606c000)
	libmpich.so.0 => /usr/lib/x86_64-linux-gnu/libmpich.so.0 (0x00007f6845bb6000)
	libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007f68459b1000)
	libslepc.so.3.09 => /home/jan/dev/slepc/local.master/lib/libslepc.so.3.09 (0x00007f6845532000)
	libpetsc.so.3.09 => /home/jan/dev/petsc/local.master/lib/libpetsc.so.3.09 (0x00007f6843ded000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6843a4f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6847ef1000)
	libboost_chrono.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.65.1 (0x00007f684384a000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f684362b000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6843427000)
	libmetis.so => /home/jan/dev/petsc/local.master/lib/libmetis.so (0x00007f68431bf000)
	libcr.so.0 => /usr/lib/libcr.so.0 (0x00007f6842fb4000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6842dac000)
	libopenblas.so.0 => /home/jan/dev/petsc/local.master/lib/libopenblas.so.0 (0x00007f6841dac000)
	libsuperlu.so.5 => /home/jan/dev/petsc/local.master/lib/libsuperlu.so.5 (0x00007f6841b37000)
	libsuperlu_dist.so.5 => /home/jan/dev/petsc/local.master/lib/libsuperlu_dist.so.5 (0x00007f68418ae000)
	libmpichfort.so.0 => /usr/lib/x86_64-linux-gnu/libmpichfort.so.0 (0x00007f6841676000)
	libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f6841297000)
	libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f6841057000)

Indeed the compiled module depends on many things and amongst other on dolfin version by depending on libdolfin.so.2018.2.

[garth-wells]

Ok, this is an example of where the version is needed (at the moment).

The plan is to remove support for code like Expression('x[0]', degree=1), since this can be more elegantly done in dolfinx using NumPy-style vectorisation. (And the code behind-the-scenes to support compiled Expression is horrendous.)

On a wider note, it would be ideal if the auto-generated code (i.e., code generated transparently to the user) has no DOLFIN dependencies. We should aim towards this.

[chrisrichardson]

So, shall we merge or delete this PR?

[blechta]

This is not clear to me. I don't consider the solution good. The issue is: 1. jitted modules have dependecies, hence 2. dependencies have to be hashed. But hashing dolfin version is not taking care of 2. completely.

(I pretty much opened the PR as a bug report, with backport of dolfin-old fix-hack.)