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
FindMatlab.cmake
Description: Binary data
On 06 Mar 2014, at 17:52, Brad King <[email protected]> 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 >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
