[cmake-developers] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Hi again,

I did some progress on this topic, slowly as usual. 

> On 16 Oct 2014, at 16:28, Brad King <brad.king at kitware.com> wrote:
> 
> On 10/13/2014 02:23 PM, Raffi Enficiaud wrote:
>> I had a hard time making some stuff compile again with Matlab under Linux.
>> The fact is that Matlab is shipped with its own version of libC, libhdf5,
>> libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc)
>> but the subminor versions are not. If I understand properly, the fact that
>> the filenames are the same prevents the dynamic loader of Linux to load the
>> files that are referred by the mex file in their respective rpath (there
>> is only one libhdf51.8.2.so in the matlab process).
> 
> It's the SONAME that matters for the dynamic loader to find the libraries
> at runtime.  It is a string copied into the dependents and used by the
> dynamic loader to find the matching file at runtime.

Even with different SONAMES, the symbols may clash. I do not know exactly how it works, but the symbols brought by an SO are not in a specific namespace and might conflict with symbols from other SOs. If there is a proper way of saying that a particular shared library needs the symbols from a particular SO, and then uses these symbols only, then it should work. I tested with symbol mapping files but I could not get it to work. The latter solution is more portable at least.

> 
>> Beside that, the
>> symbols also may clash: I had an implementation with a dynamic loader under
>> linux, but yet the boost symbols of my mex files were not loaded because
>> same symbols were already there in the process.
>> I found a technical solution to this on Linux:
>> - the use of -Wl,--exclude-libs,ALL for the linker.
> 
> According to "man ld" that option is only available on specific systems
> (i386 PE).  As you pointed out it is not available on OS X.
> 
> I think the only reliable way to do this is to make sure your plugins
> are built against the same libraries as Matlab, or to mangle the
> symbols in your dependencies so they don't conflict with Matlab.

This is not always possible:
- Matlab does not ship the headers
- Matlab has a lot of dependencies
- I experienced problems even with the same version (example of HDF5 - same subminor - and libC - different subminor)

> 
> This is outside the scope of what I think the FindMatlab module can
> achieve, so it will have to be left to the application author.
> For now please leave out the REDUCE_VISIBILITY option.  I think
> functionality like that, if provided by CMake, should be a more
> general feature not specific to FindMatlab.

Ok. What do you think about mimicking the mex compiler in terms of options set to the compiler? The -Wl,--exclude-libs,ALL is in fact set by the mex compiler for compiling the mex extensions under Linux. Then I will just drop the REDUCE_VISIBILITY from the interface and add some doc about the "best practices" that work better.

> 
>> I am using this FindMatlab in two projects now, under OSX 10.9,
>> Win7 Visual2013 and Ubuntu12.04.
> 
> Great.  In order to keep the module working, we will also need tests
> for it.  Please look at adding to the Tests/ directory a case for
> using this module.  The test case can be something we enable with
> some explicit option.  Then you can run a nightly build of CMake on
> a machine of each platform with Matlab installed and enable the test.
> Ideally you would have one for Windows, OS X, and Linux, at least.
> Without regular testing the functionality is bound to regress as
> changes are made to CMake.

I added some tests:
https://github.com/raffienficiaud/CMake/tree/matlab_wrapper/Tests/Module/Matlab2

But I have a quick question about the proper way of adding a test:
https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/CMakeLists.txt#L3095-L3099

So I am declaring tests in the CMakeLists.txt of the Matlab module test, and I am running ctest with the current configuration in order to run these tests. Is that the way of doing correctly this? If these tests should be ran in a nightly build process, should I add these tests only if Matlab is available? What are the best practices?
For instance, this test
https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/Module/Matlab2/test_should_fail/CMakeLists.txt

should fail because of a component lacking the the find_package option, and I test it with this:
https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/CMakeLists.txt#L3099

but I do not know if this is the right way to go.


I also changed the 
set(MATLAB_ADDITIONAL_VERSIONS
       "release_name1" "corresponding_version1"
       "release_name2" "corresponding_version2"
to

set(MATLAB_ADDITIONAL_VERSIONS
       "release_name1=corresponding_version1"
       "release_name2=corresponding_version2"

as you suggested in an earlier post.

Best,
Raffi

> 
> Thanks,
> -Brad