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

[Raffi Enficiaud]

Hi all,

After Brad’s feedbacks, I did the following:
- fix + clean the documentation
- remove any unwanted message, added a variable in order to print diagnostic
- cleaned variable/function names
- changed macros to function
- added components: mex compiler, eng/mx libraries, matlab program
- proper version testing
- making use of FindPackageHandleStandardArgs for the version + components + variables

The doc runs ok. I avoided using the new syntax of cmake 3.x because I am still using 2.8.12, and I also would like ppl to get this new package and run it on older versions.

The set of variables that are defined in this implementation is a superset of the current package. So it meets your definition of compatible. However, I do not have older versions of Matlab available, so I cannot say for sure it should work with any currently supported installation. 

What remains is mainly the unit test functions. Currently, what I do is this, and this works:

  add_test(NAME matlabtest-1
            COMMAND ${MATLAB_PROGRAM} ${MATLAB_UNIT_TESTS_CMD} -logfile ${CMAKE_BINARY_DIR}/matlabtest_1.log 
           -r "addpath('$<TARGET_FILE_DIR:my_mex_target>', '${CMAKE_SOURCE_DIR}/test', '${Boost_LIBRARY_DIRS}'); path, runtests('matlab_unit_tests'), exit(max([ans(1,:).Failed]))")
  set_tests_properties(matlabtest-1 PROPERTIES TIMEOUT 30)

where MATLAB_UNIT_TESTS_CMD is a set of platform specific options for launching Matlab.

While the solution is not very elegant, it provides the results expected. The reason why I do not find this elegant is that the real output of Matlab goes to a log file. This is needed because on windows, it is impossible to get the output otherwise (the instance is running in another window).
- Do you have by chance a mean to address that? like a post-test function that is alway ran after a test? That way, the log file may be consumed directly by the test framework in order to have the output in the test logs. The current solution I am seeing now is to do a test on a cmake script that does the job of launching the command and flushing the log file onto the console. 
- Is it ok if we create log files of leave them onto the disk? Maybe in a Matlab directory? This might be advantageous: eg. some continuous build server may parse them in order to create junit files 


Another question I have is for Windows. The module looks into the registry for Matlab installations. However, there are two modes for querying the registry: x86 and x64 modes. This is not very clear to me what I should do on that:
for instance, having a generator WIN64 does not mean that we should have Matlab WIN64: the user might be interested in just running Matlab and not linking to the Matlab libraries. 
There should be some other modules that have this problem I think. What would be the best strategy to separate the notions of binary that can be run on several architecture, from the notion of thirdparty artifacts needed to construct the project? Python for instance separates the libraries from the interpreter. 


I hope this goes to the right direction!

Best,
Raffi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindMatlab.cmake
Type: application/octet-stream
Size: 27118 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140409/e374229e/attachment-0001.obj>
-------------- next part --------------


On 06 Mar 2014, at 17:52, Brad King <brad.king at kitware.com> wrote:

> On 03/05/2014 05:46 PM, Raffi Enficiaud wrote:
>> So, I began writing the doc of the module and changed the license
>> according to the instructions.  I am attaching the module to the email.
> 
> Thanks!
> 
> The documentation so far is a good start but it looks like you're
> still working on it.  You can copy the module into CMake on top
> of the current FindMatlab.cmake locally, install sphinx-build, and
> then enable SPHINX_HTML in your local CMake build tree to build the
> documentation.  It will appear in Utilities/Sphinx/html.
> 
>> - the error messages are more or less message(STATUS... and sometimes
>>  message(FATAL_ERROR, rather than using Xxx_NOT_FOUND_MESSAGE.
>>  So basically if I set this variable to the error message and just
>>  call “return()” from the module scope, it will do the job?
> 
> The <name>_NOT_FOUND_MESSAGE variable is a feature of the helper
> module "FindPackageHandleStandardArgs".  Use that module's macro
> at the end of your module to do all the error handling and to set
> MATLAB_FOUND automatically.
> 
> Most of the STATUS messages should either be dropped or conditioned
> on the QUIET option of the invoking find_package command.  Some
> complex find modules like FindBoost have a special variable the
> user can set to get verbose debug output, e.g.
> 
> if(MATLAB_FIND_DEBUG)
>   message(STATUS ...)
> endif()
> 
>> - it looks like I am making too much use of the CACHE.
>>  However, I do not know if the variables like Xxx_INCLUDE_DIRS
>>  should go to the CACHE or to the PARENT_SCOPE.
> 
> The singular names that have find_* command calls will be cached
> by those commands.  Plural names like Xxx_INCLUDE_DIRS should just
> be set as normal variables with set() or list(APPEND), etc.  They
> do not need PARENT_SCOPE unless you are using an internal helper
> function.
> 
> CACHE entries should be used only for things that an end user
> might need to set or change to point at specific things on their
> system.
> 
>> - some of the variables should be renamed
> 
> Yes.  Also local variables like "64Build" should be renamed to
> have a prefix like "_matlab_" and then unset() at the end.
> 
>> - the version matching should be performed in the module, right ? 
> 
> Yes.
> 
> I haven't read through the module thoroughly yet but please check
> that it will be compatible with the exiting FindMatlab.cmake that
> it is replacing.  By "compatible" I mean that the same result
> variables must be made available to the calling project, even if
> documented as deprecated.
> 
> Thanks,
> -Brad
>