← Back to team overview

dolfin team mailing list archive

Re: Setting swig binary

 

On Thu, Mar 10, 2011 at 11:25:08AM -0800, Johan Hake wrote:
> On Thursday March 10 2011 11:21:42 Anders Logg wrote:
> > On Thu, Mar 10, 2011 at 11:19:38AM -0800, Johan Hake wrote:
> > > On Thursday March 10 2011 11:17:37 Anders Logg wrote:
> > > > On Thu, Mar 10, 2011 at 10:48:41AM -0800, Johan Hake wrote:
> > > > > On Thursday March 10 2011 10:39:19 Anders Logg wrote:
> > > > > > On Thu, Mar 10, 2011 at 10:29:46AM -0800, Johan Hake wrote:
> > > > > > > Hello!
> > > > > > >
> > > > > > > It should now be possible to set the swig binary and the path
> > > > > > > seperatly in the
> > > > > > >
> > > > > > > Python interface of DOLFIN. I have added two new parameters which
> > > > > > > defaults
> > > > >
> > > > > to:
> > > > > > >   parameters["swig_binary"] = "swig"
> > > > > > >   parameters["swig_path"] = ""
> > > > > > >
> > > > > > > If the binary name is in the PATH, just use the "swig_binary"
> > > > > > > parameter but if you have you own obscure place for it set the
> > > > > > > path too.
> > > > > > >
> > > > > > > Please test it...
> > > > > > >
> > > > > > > We also need to figure out how to patch the release of DOLFIN to
> > > > > > > be included in Debian, as we then envision to use swig2.0 as
> > > > > > > binary. Should this be altered in globalparameters.py where it
> > > > > > > is added, or into a seperate global_parameter_file.xml which is
> > > > > > > handed together with the distribution.
> > > > > > >
> > > > > > > I also wondered if we should flesh out the JIT releated
> > > > > > > parameters from FFC into its own dictionary. Now they polute the
> > > > > > > generated code for no reason.
> > > > > >
> > > > > > How do you mean?
> > > > >
> > > > > Now all parameters in the FFC parameters dict are included with their
> > > > > values in the generated .h/.cpp files. As this part has noting to do
> > > > > with JIT compilation, it is not nessesary to include these in the
> > > > > actuall generated code.
> > > >
> > > > Why not? Those were the parameters used to generate the code.
> > >
> > > My point is that the actuall code is not dependent on the swig binary
> > > that will or will not be used to eventually compile it.
> >
> > So you mean the swig binary parameters polute the code? ok, so the
> > result might be that if someone changes the swig binary, then that
> > might trigger a recompilation. Is that so much of a problem?
>
> Nope!
>
> But:
>
>   1) Yes, it polutes the code
>   2) We need to regenerate reference code each time we add a JIT dependent
>      parameter. I got some headeach with merging with main because of this...
>
> No big deal...
>
> > > > > However they need to be included in the signature string, when JIT
> > > > > compiling of course. I might envision something like
> > > > >
> > > > >   parameters
> > > > >   jit_parameters
> > > > >
> > > > > where the parameters controlls the generation of code and
> > > > > jit_parameters controlls the generation of swig module and the
> > > > > compilation flags of the code.
> > > >
> > > > Yes, but I don't see the problem of also including them in the
> > > > generated code. When compiling from the command-line, it's nice to be
> > > > able to look at the code to see which parameters were used. Why should
> > > > we have a special option to not include the parameters when called
> > > > from a JIT compiler?
> > >
> > > The JIT compiler is never used from the command line interface.
> >
> > No, but the same code generator (FFC) is used both from the
> > command-line and from the JIT compiler.
>
> Sure. But the code is not available for inspection for the used anyway if he
> calls it from the JIT interface.

True, but to me that sounds like an argument for doing nothing: the
user won't see the code anyway so the code can stay the same (no
special case needed for when it is called from a JIT compiler).

But I see the point of not needing to update the references when a
parameter is added which does not affect the generated code. The
question is whether we expect that to happen often so it would be
worth changing the parameter handling in FFC + DOLFIN and regenerate
the references once more...

--
Anders



Follow ups

References