On Thu, 16 Jan 2014 10:08:54 +0100 Johannes Ring <[email protected]> wrote:
> On Thu, Jan 16, 2014 at 10:06 AM, Johan Hake <[email protected]> > wrote: > > I am not sure this is the way we want to do it. get_swig_binary() > > relies on check_and_set_swig_binary() has been called previously. > > The latter can cause problems on clusters. The logic for the > > generated CMake file is that it should contain all information > > needed to compile the extension module and that it should get that > > from including the DOLFIN_USE_FILE. In that file we do not store > > any SWIG information. Instead we just call: > > > > find_package(SWIG REQUIRED) > > include(${SWIG_USE_FILE}) > > > > essentially re-configuring SWIG. We cannot avoid that, as we need > > to load the swig specific cmake macros from the SWIG_USE_FILE, but > > we could for example set SWIG_EXECUTABLE in the DOLFINConfig.cmake > > file, which is generated during configuration of DOLFIN? > > Yes, that sounds like a better fix. Now I see that there may be two (DOLFIN+UFC+...)s with different __swigversion__ which generate same code (with same hash) but in a cache there is stored one with swigversion which was triggered earlier. So the second one fails on ffc/jitcompiler.py:check_swig_version(compiled_module) So bassically, it's unsafe now to have FEniCSes with different SWIG on one system. This should be taken into account when fixing this. Jan > > Johannes > _______________________________________________ > fenics-support mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics-support _______________________________________________ fenics-support mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics-support
