On Friday 23 January 2009 11:42:58 Ola Skavhaug wrote: > On Fri, Jan 23, 2009 at 11:36 AM, Martin Sandve Alnæs <[email protected]>wrote: > > On Fri, Jan 23, 2009 at 11:27 AM, Ola Skavhaug <[email protected]> wrote: > > > On Fri, Jan 23, 2009 at 10:32 AM, Johan Hake <[email protected]> wrote: > > >> On Friday 23 January 2009 10:09:12 Martin Sandve Alnæs wrote: > > >> > On Fri, Jan 23, 2009 at 9:39 AM, Johannes Ring <[email protected]> > > >> > > > >> > wrote: > > >> > > On Thu, January 22, 2009 19:10, Johan Hake wrote: > > >> > >> On Thursday 22 January 2009 17:02:41 A Navaei wrote: > > >> > >>> Johan, > > >> > >>> > > >> > >>> Thanks, instant-clean did the trick! Maybe this should be > > >> > >>> somehow automated. > > >> > >> > > >> > >> Yes, I have thought about it. > > >> > >> > > >> > >> Is it possible to add a call to instant-clean in the install > > >> > >> script of > > >> > >> the ffc > > >> > >> and dolfin packages Johannes? > > >> > > > > >> > > Yes, it is possible to add post installation scripts to the FFC > > >> > > and DOLFIN packages (and perhaps Instant) that runs instant-clean. > > > > Should > > > > >> > > I > > >> > > add this? > > >> > > > > >> > > Johannes > > >> > > > >> > Can you add it to SyFi as well please? But we don't want this in > > >> > development versions though, we should at least have an option > > >> > to avoid it. > > >> > > >> I think it will be sufficient to add the automatic cleaning in the > > > > ubuntu > > > > >> scripts. > > >> > > >> I can add the swig version to the signature generation in ffc and > > > > dolfin. > > > > >> While on the topic, does instant check whether swig is installed, when > > >> a module is built? Also I have on several occasions now checked for > > >> the > > > > swig > > > > >> version. Should I put this code in instant, e.g. > > >> > > >> check_swig_version("1.3.35") > > >> > > >> It will return false if the current swig version is lesser than > > > > "1.3.35"? > > > > >> I > > >> think it would be natural for instant to provide such a function. > > > > > > There is a related problem that needs to be adressed here. If you build > > > > an > > > > > extension of a module wrapped with version x of swig, you should > > > require > > > > the > > > > > same version of swig in instant. Perhaps the > > > check_swig_version("1.3.35") should only return true if you have > > > exactly that version. Another > > > > function, > > > > > a-la > > > > > > assert_swig_min_version("1.3.35") > > > > > > could be used to make sure you got a recent enough swig. > > > > > > For example, if I have built dolfin with version 1.3.36 of swig, and > > > then upgraded swig to 1.3.37, chances are good that the type info in > > > the instant-generated extension (swig v1.3.36) will not be compatible. > > > > > > Ola > > > > Good point. It would be nice if we could detect inconsistencies like > > this at run time. > > > > Maybe PyDOLFIN can have an attribute __swigversion__, > > which can be passed to Instant at import time to check for > > compatible SWIG versions. > > > > Martin > > This should be easy, since swig defines a macro for this: > > If you need to work with different versions of SWIG and backwards > compatibility is an issue, you can use the SWIG_VERSION preprocessor symbol > which holds the version of SWIG being executed. SWIG_VERSION is a > hexadecimal integer such as 0x010311 (corresponding to SWIG-1.3.11). This > can be used in an interface file to define different typemaps, take > advantage of different features etc: > > #if SWIG_VERSION >= 0x010311 > /* Use some fancy new feature */ > #endif > > Note: The version symbol is not defined in the generated SWIG wrapper > file. The SWIG preprocessor has defined SWIG_VERSION since SWIG-1.3.11.
This sounds a bit overkill. Why make the check in the produced swig interface file, when we rather could make the check in the python function producing the interface file. Johan _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
