[Nexus-developers] SWIG NeXus interface

[Mark Koennecke]

Dear Ray,

On Wed, 20 Nov 2002, Ray Osborn wrote:

> On 2002/11/20 7:37, "Mark Koennecke" <Mark.Koennecke at psi.ch> wrote:
> 
> Hi Mark,
> I think that it would be helpful for the other developers to try it out
> before we release it to the public.  I played around with SWIG, and soon
> realized that it raises a number of issues, e.g., Python seemed to require
> the NXhandle pointer to be initialized as a null pointer before the first
> call to NXopen.  I don't know if you have solved all those problems, but I
> would like to see what you've done and then discuss how the user will want

  No I cannot solve all those problems. I do not speak all SWIG's possible 
  scripting languages. I tested with two: mzscheme and Tcl. I especially
  would like to have a perl specialist look at it, as perl is very popular. 
  I also would want to add a function for retrieving NeXus errors to the
  interface before I put it anywhere.  But this is a quick job. 

> to use it. Why don't you add a swig directory to the CVS server?
> 
  Exactly this is what I wanted. It would be NeXus/nxinter or, if you
  prefer that, NeXus/swig. Or do you mean as a separate package on the
  CVS server? 

> I am not experienced in setting up an autoconf installation, but I think we
> need to have a base installation as default, with other facilities added as
> options in the configure script.  For example, not everyone needs jnexus so
> make that an option.  What is considered to be standard and what optional is
> something we should debate.  How about:
> 
> Standard
> --------
> C + F77 API, test programs, NXbrowse, NXto...
> 
> Optional
> --------
> F90 API, Jnexus, NXdict, NDS (not currently on CVS server)
> 

  I think the SWIG interface autonconfed would be a great deal of work:
  you would have to check for SWIG and then scripting languages and give
  the user an opportunity to select a scripting language. I think we
  should defer this and concentrate to get autoconf for the main NeXus-API
  right.
  
  Dividing the package along the lines indicated seems to be a good idea.
  There is no problem of putting the NDS on the server. It is known to
  work both on True64Unix and Linux. I also would add our IDL-API.


                      Regards,

			     Mark