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

[Lionel Fafchamps]

Dear Roger,

Thanks a lot for your help! Indeed, setting the OME_HOME environment 
variable seems to have done the trick. The example file is now 
generating the expected output.

My current build configuration is essentially what you were hinting at:  
I just added libraries to the linker input until the errors went away - 
hence my suspicion something might have been off with my build 
configuration.

Thanks again!

Lionel

On 2016-10-26 14:35, Roger Leigh wrote:
> 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