dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Friday 23 January 2009 11:42:58 Ola Skavhaug wrote:
> On Fri, Jan 23, 2009 at 11:36 AM, Martin Sandve Alnæs 
<martinal@xxxxxxxxx>wrote:
> > On Fri, Jan 23, 2009 at 11:27 AM, Ola Skavhaug <skavhaug@xxxxxxxxx> wrote:
> > > On Fri, Jan 23, 2009 at 10:32 AM, Johan Hake <hake@xxxxxxxxx> 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 <johannr@xxxxxxxxx>
> > >> >
> > >> > 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