dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

On Fri, Jan 23, 2009 at 11:51 AM, Johan Hake <hake@xxxxxxxxx> wrote:

> 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
>


That's not my point. Just that swig has a notion of version, that could be
exported to the proxy layer automatically. You don't want to manually input
the swig version in the generated wrappers.


-- 
Ola Skavhaug