[ome-devel] [ome-files] Getting Exceptions When Opening Files for setId(...)

[Roger Leigh]

On 18/02/18 20:08, Dennis Ai wrote:
> Hi Roger,
>
> Sorry for the late reply.  Have been working on other non-related tasks lately, and it took me a while how to figure out how to get Visual Studio to step into ome-files code.  Here are the results.
>
> =======================================================================
> Breakpoint at ome/common/module.cpp#L404
> It turns out that module references three environment variables, module.envvar="OME_XML_SCHEMADIR", module.module_envvar="OME_XML_HOME", and module.root_envvar="OME_HOME".  Given that we were setting OME_FILES_HOME variable before, it makes sense that all these checks were being skipped.  If I set OME_XML_HOME, then:
>
> home evaluates to C:\Users\...\Documents\Visual Studio 2015\Projects\OMEFilesSharp\External\ome-filesd"
> home /= module.relpath evaluates to C:\Users\...\Documents\Visual Studio 2015\Projects\OMEFilesSharp\External\ome-filesd\share/xml/ome
>
> If I type that joined path into explorer, it takes me to the right directory.  Everything else checks out, the path gets resolved, module.realpath is returned, and my unit test that runs open() succeeds.  Thanks so much for your help!

Super, I'm very glad you've got this all working!

> I am curious though, is there a production solution that doesn't require setting an environment variable?

For Linux, MacOS X and FreeBSD, this works completely transparently via
introspection of the install path of the shared library.  The
environment variables can be used to override the defaults, but are
unnecessary for typical usage.

For Windows, we can't do this until we can build DLLs in place of the
static libraries, which I tried to explain in my previous reply.  Right
now on Windows, the environment variables are the only way to tell the
runtime where the data-files are located.  It's certainly something
which should be improved to make usage in production completely
foolproof and transparent.  The problem is in the existing usage of
templates in the library API which are somewhat incompatible with the
restrictions the DLL interface imposes.  If we can figure out a way to
make a DLL without sacrificing the usability of the API, then we would
be very keen to enable this functionality.  If you had any suggestions
I'd be very pleased to consider them; I'm not an expert regarding the
intricacies of DLL limitations, and if there's any way to export all the
template specialisations safely in each of our libraries I'd love to do so.


Kind regards,
Roger

--
Dr Roger Leigh -- Open Microscopy Environment
Wellcome Trust Centre for Gene Regulation and Expression,
College of Life Sciences, University of Dundee, Dow Street,
Dundee DD1 5EH Scotland UK   Tel: (01382) 386364

The University of Dundee is a registered Scottish Charity, No: SC015096