[ome-devel] Difficulty building windows applications with ome-files C++

[Roger Leigh]

On 26/10/16 12:45, Lionel Fafchamps wrote:
> Hi,
>
> We are trying to build a microscopy software suite using Qt and would
> like to be able to save OME-Tiff files as our default file option, since
> these are easily compatible with most image manipulation suites and the
> metadata is also easily accessed.
>
> I’ve been having some trouble building working windows applications with
> the OME-files C++ library (version 0.2.2).  I’m currently using VC14 on
> Windows 10, and I’ve tried x64 and x86 configurations with both the
> release and debug versions of the libraries.  In order to test my build
> configuration, I’m building the metadata-formatwriter.cpp example.
>
> Generally speaking, everything appears to work on the surface, but
> running the executable I always get the following exception: “Invalid
> OME-XML document” upon calling the close() method of the OMETiffWriter.
> The resulting tiff file seems to contain all of the pixel data, but the
> metadata is missing from the file.  I’ve tried building the same example
> file from Linux and it appears to work correctly.
>
> Has anyone ever spotted this problem before, and could it be there’s
> something wrong with my build configuration somehow?  Are there any
> examples of build configurations under windows?

Dear Lionel,

I think that what's happening is that it's trying to validate against
the schema but it's failing to find the needed schema file.

The schema files and transforms used for processing and validating
OME-XML might not be found.  On Unix platforms, these are on the install
path or are found as a relative path by autodetection via the shared
library path.  On Windows this should also work for DLLs (there's code
to do this), but we currently only build shared libraries.  You could
try setting the OME_HOME environment variable to explicitly set the root
of the installation, which will be used to find the needed datafiles.
(See the "ome-files.bat" program which sets up the environment for our
test programs as an example of what we set.  The single environment
variable should be sufficient though.)

In a future release, we will work to enable the building of DLLs on
Windows to make this much more transparent.


Another possibility could be that the metadatastore/model APIs have been
used to generate invalid metadata which results in a non-validating XML
document, which is possible if called in the wrong order or which
introduce inconsistencies in the metadata.  However, if you're only
using the provided examples, this should not happen since they are run
daily as part of the unit tests and we know they work on Windows and
pass the validation steps.


Regarding build configurations, we build the set of libraries and their
dependencies using CMake with various Visual Studio versions and
configurations, and we provide CMake exported configuration files in
each build for use by downstream projects.  They are optional; you can
select the libraries by hand and link that way, but since the libraries
are static you will need to also specify the needed transitive
dependencies.  They will be listed in the CMake configuration file in
the binary download.

% grep INTERFACE_LINK_LIBRARIES cmake/OME*Internal.cmake
cmake/OMECommonInternal.cmake:  INTERFACE_LINK_LIBRARIES
"ome_compat_ome-compat;Boost::log_setup;Boost::log;Boost::iostreams;Boost::filesystem;Boost::system;XercesC::XercesC;XalanC::XalanC"
cmake/OMECompatInternal.cmake:  INTERFACE_LINK_LIBRARIES "Boost::boost"
cmake/OMEFilesInternal.cmake:  INTERFACE_LINK_LIBRARIES
"OME::Compat;OME::Common;OME::XML;Boost::boost;Boost::iostreams;Boost::filesystem;TIFF::TIFF"
cmake/OMEXMLInternal.cmake:  INTERFACE_LINK_LIBRARIES
"OME::Compat;OME::Common;Boost::date_time"

These are the CMake names for the individual library dependencies for
each library.  If linking manually, you'll need to link with all of them
explicitly; these will get progressively hidden as we switch over to
DLLs, and also drop dependencies as C++11 replaces the need for some of
them.


Once we build DLLs in place of static libraries, making use of the
libraries should become much easier.

We have recently been working upon modularising the libraries into
separate git repositories, and developing the intrastructure
(ome-cmake-superbuild) to build the collection.  This will let us build
the examples as separate projects so that we can provide examples of
integrating the libraries as standalone usable projects rather than
integrated into the main build.  This should hopefully make things a bit
clearer, and also serve as testcases for downstream project builds in
our daily testing.


I hope the above is useful, if there's anything unclear or I've
misunderstood the questions, please get back in touch!


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