[cmake-developers] Introduction and volunteering for the Matlab package
Hello, My name is Raffi Enficiaud. I am volunteering myself for maintaining the Matlab package. In fact, I wrote a Matlab package that I am currently using on Mac and Win in Bamboo continuous build (and in the near future on Ubuntu). I already gave some of the functionalities in the following mantis ticket: http://www.cmake.org/Bug/view.php?id=14641 I would like to release this to the cmake community and to maintain it. Waiting for your feedbacks, Best, Raffi Enficiaud -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi Brad,(Sorry for the late answer (again).)I addressed your comments in the files attached to this email (please see the remarks below). I have not yet addressed your comment about “MATLAB_ADDITIONAL_VERSIONS” but I think it is a better proposition, so I will do it next.I updated the documentation also, I think it looks now understandable.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). 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. - the symbol hiding (both include and function definition) from within the mex file- exporting only the mexFunction symbolI know that this scheme is working for statically linked libraries, that then should be recompiled with -fPIC. I know also that this is working for shared libraries that do not have the same name (eg. boost1.49.so vs. boost1.55.so). But I think there is nothing more I can do for the shared library having the same name (like hdf51.8.2.so), having the same symbols but apparently having a different ABI.I do not know how to do that properly under OSX neither. There is no -Wl,--exclude-libs,ALL option in Clang.Also, I am checking against CMAKE_CXX_COMPILER_ID, which is I think a not so good idea. Is there anything for having the -Wl,--exclude-libs,ALL like the variable CXX_VISIBILITY_PRESET in cmake? I started using a .map file on these two platforms, but also I would prefer limiting the number of files. I am using this FindMatlab in two projects now, under OSX 10.9, Win7 Visual2013 and Ubuntu12.04. Best,Raffi
FindMatlab.cmake
Description: Binary data
MatlabTestsRedirect.cmake
Description: Binary data
——Hi Raffi,Thanks for your continuing work on this module.I've made some whitespace and quoting tweaks to the files. See attachedupdated versions. I also renamed the test helper to not start in "Find"since no one should call find_package(Matlab_TestsRedirect). See furthercomments below.On 07/04/2014 08:02 PM, Raffi Enficiaud wrote:Many of our tests use "cmake -P" to run a cmake script that performsthe test inside. You can use -Dvar=${val} before the -P option topass options to the script, such as $.Done: this is the add_matlab_unit_test function. In fact, I think I canremove the log files since they are redundant with the tests logs.I see no problem with that, but I'm not familiar with the tools.I added a function add_matlab_mex that is like a add_libraryPlease make all APIs start in "matlab_”.DoneThe documentation blocks for each command also need to start in "#.rst:"#.rst:# .. command:: add_matlab_mexor they will not be included in the processed documentation.Ok. I checked the documentation again, and I think it contains now all the necessary information, plus it is now visually more appealing. for creating MEX (compiled) extensions. There is an option to thisfunction called REDUCE_VISIBILITYI see that implemented here:if(HAS_VISIBILITY_INLINE_HIDDEN) target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility-inlines-hidden")endif()if(HAS_VISIBILITY_HIDDEN) target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility=hidden")endif()An upstream version of the module should use the builtin featuresfor visibility settings:http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.htmlhttp://www.cmake.org/cmake/help/v3.0/prop_tgt/VISIBILITY_INLINES_HIDDEN.htmlI am not sure how to do that, please have a look at my changes. It looks ok to me (generated compilation command include the visibility element) but maybe there is something better.# set(MATLAB_ADDITIONAL_VERSIONS# "release_name1" "corresponding_version1"# "release_name2" "corresponding_version2"# ...# )Rather than relying on matched pairs, perhaps use "=" to separate:# set(MATLAB_ADDITIONAL_VERSIONS# "release_name1=corresponding_version1"# "release_name2=corresponding_version2"?Right, it is better.I am not sure how my implementation is compatible with the previousFindMatlab package. The requirements are to define the same variables,right? Is there anything else?It needs to produce the same result variables and also respond tothe old "input" variables (like find_ command cached results) thatthe old module did. That way existing build scripts can continueto work.This is something I should now check deeper. Is it an option to call it FindMatl
Re: [cmake-developers] Introduction and volunteering for the Matlab package
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. > 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 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. > 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. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi again, I did some progress on this topic, slowly as usual. > On 16 Oct 2014, at 16:28, Brad King 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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 01/21/2015 12:01 PM, Raffi Enficiaud wrote: > 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 think suggesting it in the documentation is fine. If some common cross-platform solutions evolve then we can revisit adding official support. > But I have a quick question about the proper way of adding a test: [snip] > should fail because of a component lacking the the find_package option The best place to put tests covering bad CMake code and error cases is under the Tests/RunCMake infrastructure. That allows explicit matching of return codes and error messages. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi, I added a section "known problems" in the documentation and removed the REDUCE_VISIBILITY option. I am keeping the hidden symbols of the compiled MEX file as it appears to be something properly supported. This behaviour is also documented. I moved the test for bad configuration under RunCMake with appropriate error message and return code. How do we proceed next? Best, Raffi Enficiaud > On 21 Jan 2015, at 22:30, Brad King wrote: > > On 01/21/2015 12:01 PM, Raffi Enficiaud wrote: >> 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 think suggesting it in the documentation is fine. If some common > cross-platform solutions evolve then we can revisit adding official > support. > >> But I have a quick question about the proper way of adding a test: > [snip] >> should fail because of a component lacking the the find_package option > > The best place to put tests covering bad CMake code and error cases > is under the Tests/RunCMake infrastructure. That allows explicit > matching of return codes and error messages. > > 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 01/22/2015 10:13 AM, Raffi Enficiaud wrote: > How do we proceed next? Please attach a copy of the patch with the latest revisions. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Attached to this email. I can also do a pull request if you prefer, Best, Raffi Enficiaud FindMatlab.cmake Description: Binary data MatlabTestsRedirect.cmake Description: Binary data > On 22 Jan 2015, at 17:48, Brad King wrote: > > On 01/22/2015 10:13 AM, Raffi Enficiaud wrote: >> How do we proceed next? > > Please attach a copy of the patch with the latest revisions. > > 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 01/22/2015 11:50 AM, Raffi Enficiaud wrote:
> I can also do a pull request if you prefer,
As described in CONTRIBUTING.rst a patch here is preferred.
I've fetched your branch from https://github.com/raffienficiaud/CMake
Here are some comments.
Please wrap text in the documentation blocks of the FindMatlab
module to fit in 79 columns.
> #find_package(Matlab
> # [VERSION]
> # [REQUIRED]
> # [COMPONENTS component1 [component2]])
Individual find modules don't need to summarize the find_package
signature. Documentation of components and versions can just
refer to the :command:`find_package` command and name the options.
> # .. note:
> #
> # The version above is the Matlab version...
The note text needs to be indented to be part of the note. The same
goes for all the variable and command documentation inside explicit
markup directives like ".. variable::" and ".. command::".
> # User defined variables
> # --
This section should be called something like "Module Input Variables"
and have intro wording like "Users or projects may set the following
variables to configure this module behavior.".
> # Variables defined by the module
> # ---
This section should distinguish between cache entries and output
variables. See FindJsonCpp for an example.
> # Provided macros
> # ---
Generally we try to use functions with "set(... PARENT_SCOPE)".
Also on the endmacro() and endfunction() calls please drop the
command name.
> # WARNING: this thing pollutes the CMAKE_FIND_LIBRARY_PREFIXES global
> variable.
> # Should it be restored afterwards? Is there a more appropriate way to do
> that?
> set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES}
> ${_matlab_lib_prefix_for_search})
This should be handled with a save/restore.
> # The function arguments are:
Please use definition lists instead of bullet lists for function
argument documentation.
The copyright year should be 2014-2015 since we've spilled into
that range. There is no need for copyright notices in the
Tests/RunCMake test cmake code because there no creative input
in that boilerplate.
Please remove all trailing whitespace and make sure the files are
committed with LF newlines and not CRLF newlines (including tests).
Also make sure all files end in a newline (but not trailing blank
lines).
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 01/23/2015 07:52 PM, Raffi Enficiaud wrote: >> This should be handled with a save/restore. > > Are you referring to the CMakePushCheckState? No, CMAKE_FIND_LIBRARY_PREFIXES should be saved/restored manually with code in the Find module around the find_library calls. You could also create a _Matlab_find_library function that sets CMAKE_FIND_LIBRARY_PREFIXES and calls find_library. The setting would go out of scope when the function returns. See the FindBoost module for a similar example. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Dear Brad, I addressed your proposed solution and sent you a patch, that is pending approval since this afternoon because of a size exceeding 300KB. Best regards, Raffi Enficiaud > On 26 Jan 2015, at 14:43, Brad King wrote: > > On 01/23/2015 07:52 PM, Raffi Enficiaud wrote: >>> This should be handled with a save/restore. >> >> Are you referring to the CMakePushCheckState? > > No, CMAKE_FIND_LIBRARY_PREFIXES should be saved/restored manually > with code in the Find module around the find_library calls. You > could also create a _Matlab_find_library function that sets > CMAKE_FIND_LIBRARY_PREFIXES and calls find_library. The setting > would go out of scope when the function returns. See the FindBoost > module for a similar example. > > -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 01/28/2015 09:21 AM, Raffi Enficiaud wrote: > I am wondering why I haven't zipped the patch before. > > Please find attached the patch addressing the issues you raised. The reason it was so big is because you sent an entire patch series containing your local development history. Instead please squash everything down to a single commit so "git format-patch" generates a patch with only one commit. I did this locally and produced the attached patch from your changes, rebased on master as of commit aec11372. You could start a new branch from there, "git am" the attached patch, edit files, use "git commit --amend" to update it, and then "git format-patch" to send it back. Please revise the commit message to summarize all the work done by these changes. In order to make the tests available only when enabled explicitly on a machine with Matlab installed, please revise the test cases to use the pattern used for FindJsonCpp. Look for code refering to CMake_TEST_FindJsonCpp for an example. The same check can be used in the RunCMake directory too. Use -DCMake_TEST_FindMatlab=1 on the CMake command line locally to get the tests enabled for you. Later we will expect you to run nightly testing for this since our dashboard machines do not have Matlab. Also, please rename: Tests/Module/Matlab2/ => Tests/FindMatlab/ Tests/RunCMake/Matlab2/ => Tests/RunCMake/FindMatlab/ Thanks, -Brad >From 250c78d0ed5637cb954e821284e999ceb0cfcd76 Mon Sep 17 00:00:00 2001 Message-Id: <250c78d0ed5637cb954e821284e999ceb0cfcd76.1422993185.git.brad.k...@kitware.com> From: Raffi Enficiaud Date: Tue, 3 Feb 2015 14:52:15 -0500 Subject: [PATCH] FindMatlab: Rewrite module and provide a usage API --- Modules/FindMatlab.cmake | 1423 ++-- Modules/MatlabTestsRedirect.cmake | 80 ++ Tests/CMakeLists.txt |4 + Tests/Module/Matlab2/basic_checks/CMakeLists.txt | 57 + Tests/Module/Matlab2/cmake_matlab_unit_tests1.m| 33 + Tests/Module/Matlab2/cmake_matlab_unit_tests2.m|6 + Tests/Module/Matlab2/cmake_matlab_unit_tests3.m|5 + .../Matlab2/cmake_matlab_unit_tests_timeout.m | 15 + Tests/Module/Matlab2/help_text1.m.txt |2 + Tests/Module/Matlab2/matlab_wrapper1.cpp | 26 + .../Module/Matlab2/versions_checks/CMakeLists.txt | 52 + Tests/RunCMake/CMakeLists.txt |3 + Tests/RunCMake/Matlab2/CMakeLists.txt |3 + Tests/RunCMake/Matlab2/MatlabTest1-result.txt |1 + Tests/RunCMake/Matlab2/MatlabTest1-stderr.txt |2 + Tests/RunCMake/Matlab2/MatlabTest1.cmake | 22 + Tests/RunCMake/Matlab2/RunCMakeTest.cmake |3 + Tests/RunCMake/Matlab2/cmake_matlab_unit_tests2.m |6 + Tests/RunCMake/Matlab2/matlab_wrapper1.cpp | 26 + 19 files changed, 1682 insertions(+), 87 deletions(-) create mode 100644 Modules/MatlabTestsRedirect.cmake create mode 100644 Tests/Module/Matlab2/basic_checks/CMakeLists.txt create mode 100644 Tests/Module/Matlab2/cmake_matlab_unit_tests1.m create mode 100644 Tests/Module/Matlab2/cmake_matlab_unit_tests2.m create mode 100644 Tests/Module/Matlab2/cmake_matlab_unit_tests3.m create mode 100644 Tests/Module/Matlab2/cmake_matlab_unit_tests_timeout.m create mode 100644 Tests/Module/Matlab2/help_text1.m.txt create mode 100644 Tests/Module/Matlab2/matlab_wrapper1.cpp create mode 100644 Tests/Module/Matlab2/versions_checks/CMakeLists.txt create mode 100644 Tests/RunCMake/Matlab2/CMakeLists.txt create mode 100644 Tests/RunCMake/Matlab2/MatlabTest1-result.txt create mode 100644 Tests/RunCMake/Matlab2/MatlabTest1-stderr.txt create mode 100644 Tests/RunCMake/Matlab2/MatlabTest1.cmake create mode 100644 Tests/RunCMake/Matlab2/RunCMakeTest.cmake create mode 100644 Tests/RunCMake/Matlab2/cmake_matlab_unit_tests2.m create mode 100644 Tests/RunCMake/Matlab2/matlab_wrapper1.cpp diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake index 474556e..a821826 100644 --- a/Modules/FindMatlab.cmake +++ b/Modules/FindMatlab.cmake @@ -2,20 +2,201 @@ # FindMatlab # -- # -# this module looks for Matlab +# Finds Matlab installations and provides Matlab tools and libraries to cmake. # -# Defines: +# This package first intention is to find the libraries associated with Matlab +# in order to be able to build Matlab extensions (mex files). It can also be +# used: # -# :: +# * run specific commands in Matlab +# * declare Matlab unit test +# * retrieve various information from Matlab (mex extensions, versions and +# release queries, ...) # -# MATLAB_INCLUDE_DIR: include path for mex.h, engine.h -# MATLAB_LIBRARIES: required libraries: libmex, etc -# MATLAB_MEX_LIBRARY: path to libmex.lib -# MATLAB_MX_LIBRARY: path to libmx.lib -# MATLAB_ENG_LIBRARY: path to libeng.lib +# The module supports the following components: +# +# * ``MX_LIBRARY`` and ``ENG_LIBRARY``
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Dear Brad, Thanks for the feedback. I will implement your suggestions. I suppose there is some documentation on how to set up a night test server, but I could not find any. Would you please help me with this? Regards, Raffi Enficiaud > On 03 Feb 2015, at 20:59, Brad King wrote: > > In order to make the tests available only when enabled explicitly > on a machine with Matlab installed, please revise the test cases > to use the pattern used for FindJsonCpp. Look for code refering > to CMake_TEST_FindJsonCpp for an example. The same check can be > used in the RunCMake directory too. Use -DCMake_TEST_FindMatlab=1 > on the CMake command line locally to get the tests enabled for you. > Later we will expect you to run nightly testing for this since our > dashboard machines do not have Matlab. > > Also, please rename: > > Tests/Module/Matlab2/ => Tests/FindMatlab/ > Tests/RunCMake/Matlab2/ => Tests/RunCMake/FindMatlab/ > > Thanks, > -Brad > > <0001-FindMatlab-Rewrite-module-and-provide-a-usage-API.patch> -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/03/2015 06:21 PM, Raffi Enficiaud wrote: > I suppose there is some documentation on how to set up a night test server Oops, I forgot to include the link. Here: http://www.cmake.org/Wiki/CMake/Git/Dashboard Use Windows Task Scheduler to run a .bat script that runs ctest on the dashboard script you create. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Dear Brad, Please find attached the reworked patch + some more log in case of error of the matlab unit tests. I rebased the work on master rev 09cdcc5 and squashed the patch as you required. > Use Windows Task Scheduler to run a .bat script that runs ctest on the > dashboard script you create. I use Atlassian bamboo. It is really just running the commands in the page you mentioned with -DCMake_TEST_FindMatlab=1, right? I can test against several environment if you would like. I will start tomorrow. Regards, Raffi Enficiaud 0001-Implementation-of-the-new-FindMatlab-module.patch Description: Binary data -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/12/2015 11:19 AM, Raffi Enficiaud wrote: > Please find attached the reworked patch Thanks. I'll take a look when I get a chance. >> Use Windows Task Scheduler to run a .bat script that runs ctest on the >> dashboard script you create. > > It is really just running the commands in the page you mentioned with > -DCMake_TEST_FindMatlab=1, right? The definition needs to be put in the cache of the CMake build itself, not passed to the ctest script. To do that, add: set(dashboard_cache " CMake_TEST_FindMatlab:BOOL=ON ") before including the common script. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 12 Feb 2015, at 19:03, Brad King wrote: > > > The definition needs to be put in the cache of the CMake build itself, > not passed to the ctest script. To do that, add: > > set(dashboard_cache " > CMake_TEST_FindMatlab:BOOL=ON > ") > > before including the common script. > Good, I am trying this now. - Is there any convention for CTEST_SITE? Would "bambooagent.raffienficiaud" do? - What is the preferred configuration to test? Debug or Release? - Should I do some configuration on the dashboard? I have not found anything in particular, except for claiming sites. - What architectures should be tested? Thanks, Raffi Enficiaud -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi, 3 build agents (lts14.04, osx10.9 and win7x64) are now running the nightly with the CMake_TEST_FindMatlab set to ON. The site name is bambooagent.raffienficiaud @ https://open.cdash.org/viewSite.php?siteid=11851&project=1¤ttime=1423789200 Please let me know if there is anything else I should do. Best regards, Raffi Enficiaud > On 12 Feb 2015, at 23:36, Raffi Enficiaud wrote: > > >> On 12 Feb 2015, at 19:03, Brad King wrote: >> >> >> The definition needs to be put in the cache of the CMake build itself, >> not passed to the ctest script. To do that, add: >> >> set(dashboard_cache " >> CMake_TEST_FindMatlab:BOOL=ON >> ") >> >> before including the common script. >> > > Good, I am trying this now. > > - Is there any convention for CTEST_SITE? Would "bambooagent.raffienficiaud" > do? > - What is the preferred configuration to test? Debug or Release? > - Should I do some configuration on the dashboard? I have not found anything > in particular, except for claiming sites. > - What architectures should be tested? > > Thanks, > Raffi Enficiaud > > > -- > > 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/mailman/listinfo/cmake-developers -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/13/2015 05:10 AM, Raffi Enficiaud wrote: > 3 build agents (lts14.04, osx10.9 and win7x64) are now running the nightly > with the CMake_TEST_FindMatlab set to ON. > The site name is bambooagent.raffienficiaud @ > https://open.cdash.org/viewSite.php?siteid=11851&project=1¤ttime=1423789200 Those look great! The one test failure on Windows may be because the total path length gets too deep and exceeds some internal MS tool limits of 260 characters. Please move the build to somewhere with a shorter path. Usually I keep mine under 55 characters or so to the top of the build tree. In the two that use the "Unix Makefiles" generator you can also add set(CTEST_BUILD_FLAGS "-j4") # parallel build level In all three dashboard scripts you could add: set(CTEST_TEST_ARGS PARALLEL_LEVEL 4) to get tests to run in parallel. Of course you can set the levels based on the available hardware on each machine. On 02/12/2015 05:36 PM, Raffi Enficiaud wrote:> > - Is there any convention for CTEST_SITE? Would "bambooagent.raffienficiaud" > do? Yes. > - What is the preferred configuration to test? Debug or Release? The Debug you chose will be fine. > - Should I do some configuration on the dashboard? I have not found > anything in particular, except for claiming sites. Nothing more for you. Once these builds have shown up consistently for a few days I'll move them to the Nightly Expected section. > - What architectures should be tested? Anyplace that FindMatlab should be covered. I think the three you've started look good. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 13 Feb 2015, at 14:58, Brad King wrote: > > On 02/13/2015 05:10 AM, Raffi Enficiaud wrote: >> 3 build agents (lts14.04, osx10.9 and win7x64) are now running the nightly >> with the CMake_TEST_FindMatlab set to ON. >> The site name is bambooagent.raffienficiaud @ >> https://open.cdash.org/viewSite.php?siteid=11851&project=1¤ttime=1423789200 > > Those look great! > > The one test failure on Windows may be because the total path length > gets too deep and exceeds some internal MS tool limits of 260 characters. > Please move the build to somewhere with a shorter path. Usually I keep > mine under 55 characters or so to the top of the build tree. Args! I'll try to reconfigure the agent temporary build path then, but not before next week I am afraid. > > In the two that use the "Unix Makefiles" generator you can also add > > set(CTEST_BUILD_FLAGS "-j4") # parallel build level > > In all three dashboard scripts you could add: > > set(CTEST_TEST_ARGS PARALLEL_LEVEL 4) > > to get tests to run in parallel. Of course you can set the levels > based on the available hardware on each machine. I'll do that! Looks that things are on good tracks then, Thanks for driving this, Raffi Enficiaud -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/12/2015 11:19 AM, Raffi Enficiaud wrote:
> Please find attached the reworked patch
Great, thanks. Now that we have the nightly testing worked out I've
committed this with minor tweaks as a draft of the change for testing:
FindMatlab: Rewrite module and provide a usage API
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c7710e9
I have a few more comments to be addressed before merge to 'master'.
You can base further patches on the above-linked commit.
* Why is Matlab_VERSION_STRING cached? Shouldn't it be computed
every time from the matlab that was found?
* No find modules ever REALPATH the found values in case the user
has a reason to keep the symlinks. Why do we need to resolve
symlinks in Matlab_MAIN_PROGRAM?
* Several if() calls are using explicit ${VAR} variable dereferences.
Those should be converted to just if(VAR ...) to allow if() to
implicitly dereference them and avoid surprises when their value
happens to name another variable.
* I will remove the conditions on CMAKE_VERSION in the final upstream
version because we know it always runs with the current CMake
version. You'll have to maintain a small patch on your external
copy of the module for use with older CMake versions.
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi,
My comments below:
> On 13 Feb 2015, at 15:33, Brad King wrote:
>
> On 02/12/2015 11:19 AM, Raffi Enficiaud wrote:
>> Please find attached the reworked patch
>
> Great, thanks. Now that we have the nightly testing worked out I've
> committed this with minor tweaks as a draft of the change for testing:
>
> FindMatlab: Rewrite module and provide a usage API
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c7710e9
>
> I have a few more comments to be addressed before merge to 'master'.
> You can base further patches on the above-linked commit.
>
> * Why is Matlab_VERSION_STRING cached? Shouldn't it be computed
> every time from the matlab that was found?
In case the version is not found with an obvious method (on OSX
/Applications/MATLABVersion, on Win32, the version also is given by the
registry key), we have to find the version of matlab by running matlab itself.
I am caching the version once I have it to prevent any further execution of
matlab for retrieving this information. Launching Matlab is kind of heavy,
involving also network connection sometimes (due to floating license).
>
> * No find modules ever REALPATH the found values in case the user
> has a reason to keep the symlinks. Why do we need to resolve
> symlinks in Matlab_MAIN_PROGRAM?
In case a symlink of the binary called "matlab" exists in /usr/local/bin for
instance, I need to retrieve the path of the libraries mex, mx etc, that are
relative to the real installation path of matlab. This is what is happening in
my institute, the installation being made on a netshare by IT ppl, that can
switch the version in demand. When matlab is launched from a symlink, it is
executed in its installation path anyway (the matlab program is a stub to
another script), so I need also this piece of information.
>
> * Several if() calls are using explicit ${VAR} variable dereferences.
> Those should be converted to just if(VAR ...) to allow if() to
> implicitly dereference them and avoid surprises when their value
> happens to name another variable.
Ok will do.
>
> * I will remove the conditions on CMAKE_VERSION in the final upstream
> version because we know it always runs with the current CMake
> version. You'll have to maintain a small patch on your external
> copy of the module for use with older CMake versions.
No problem, hope the informations above are clear enough and justify the
choices made.
Thanks,
Raffi Enficiaud
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/13/2015 09:43 AM, Raffi Enficiaud wrote: >> * Why is Matlab_VERSION_STRING cached? Shouldn't it be computed >> every time from the matlab that was found? > > In case the version is not found with an obvious method > (on OSX /Applications/MATLABVersion, on Win32, the version also is > given by the registry key), we have to find the version of matlab > by running matlab itself. I am caching the version once I have it > to prevent any further execution of matlab for retrieving this > information. Okay. Currently the value is user-facing, but it shouldn't ever be edited manually, right? Instead the detected version could be cached in an INTERNAL cache entry. Also there should be a second internal entry that records which matlab program was executed to compute the version. If the latter does not match then the version should be re-computed. > In case a symlink of the binary called "matlab" exists in /usr/local/bin > for instance, I need to retrieve the path of the libraries mex, mx etc, > that are relative to the real installation path of matlab. In that case I think you should look for those pieces relative to the original executable location first, and if not found then resolve symlinks into a temporary variable name and then use that. The resolved path should not be made user-facing so that any user that sets Matlab_MAIN_PROGRAM explicitly will see that value persist. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/13/2015 09:33 AM, Brad King wrote: > FindMatlab: Rewrite module and provide a usage API > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c7710e9 > > I have a few more comments to be addressed before merge to 'master'. > You can base further patches on the above-linked commit. I had to add two commits to the topic to fix some continuous testing failures: FindMatlab: Fix ModuleNotices test for MatlabTestsRedirect http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ba3057ef FindMatlab: Quote variable references in macro calls http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5e91eb43 Please rebase further work on commit 5e91eb43. I will squash all this together later before merging to 'master'. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Thanks for your feedback, I will address your comments this week-end. Regards, Raffi Enficiaud > On 13 Feb 2015, at 16:36, Brad King wrote: > > On 02/13/2015 09:43 AM, Raffi Enficiaud wrote: >>> * Why is Matlab_VERSION_STRING cached? Shouldn't it be computed >>> every time from the matlab that was found? >> >> In case the version is not found with an obvious method >> (on OSX /Applications/MATLABVersion, on Win32, the version also is >> given by the registry key), we have to find the version of matlab >> by running matlab itself. I am caching the version once I have it >> to prevent any further execution of matlab for retrieving this >> information. > > Okay. Currently the value is user-facing, but it shouldn't ever be > edited manually, right? Instead the detected version could be cached > in an INTERNAL cache entry. Also there should be a second internal > entry that records which matlab program was executed to compute the > version. If the latter does not match then the version should be > re-computed. > >> In case a symlink of the binary called "matlab" exists in /usr/local/bin >> for instance, I need to retrieve the path of the libraries mex, mx etc, >> that are relative to the real installation path of matlab. > > In that case I think you should look for those pieces relative to > the original executable location first, and if not found then > resolve symlinks into a temporary variable name and then use that. > The resolved path should not be made user-facing so that any user > that sets Matlab_MAIN_PROGRAM explicitly will see that value > persist. > > 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/13/2015 10:57 AM, Brad King wrote: > I had to add two commits to the topic to fix some continuous > testing failures: > > Please rebase further work on commit 5e91eb43. I will squash > all this together later before merging to 'master'. After a few more fixes for other nightly testing failures I squashed all the changes into: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d414ca2 On your nightly submissions all the tests are passing on Windows. However, all FindMatlab-related tests fail on the other platforms. I've reverted the whole topic from 'next' for now until you have time to address these failures. Please base further patches on commit 9d414ca2. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Dear Brad, Yes, thank you, you did well. And sorry for the delay, it takes more time than expected. Best regards, Raffi Enficiaud > On 17 Feb 2015, at 16:16, Brad King wrote: > > On 02/13/2015 10:57 AM, Brad King wrote: >> I had to add two commits to the topic to fix some continuous >> testing failures: >> >> Please rebase further work on commit 5e91eb43. I will squash >> all this together later before merging to 'master'. > > After a few more fixes for other nightly testing failures I > squashed all the changes into: > > FindMatlab: Rewrite module and provide a usage API > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d414ca2 > > On your nightly submissions all the tests are passing on Windows. > However, all FindMatlab-related tests fail on the other platforms. > I've reverted the whole topic from 'next' for now until you have > time to address these failures. Please base further patches on > commit 9d414ca2. > > 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Dear Brad,
Please find attached a patch addressing the issues mentioned in your email.
The tests were failing because of the following modification:
- matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
+ matlab_get_version_from_matlab_run("${Matlab_MAIN_PROGRAM}"
matlab_list_of_all_versions)
Apparently the quotes here are interpreted as part of the binary name, which
prevents the proper call to matlab using the execute_process function.
I kept the symlink resolution, but I narrowed the case those should be
resolved. I added a variable pointing to the (symlink resolved) location of the
binary from which the version is retrieved. I compare paths symlink resolved
for that purpose. I hope this is in line with what you would like to have.
Note that I only tested on LinuxLTS14.04 locally, I will test further tomorrow
morning.
I also changed the build path of the Windows agent, the build should be clear
on Windows now.
Best regards,
Raffi Enficiaud
0001-Addressing-the-visibility-of-the-internal-variables-.patch
Description: Binary data
> On 13 Feb 2015, at 16:36, Brad King wrote:
>
> On 02/13/2015 09:43 AM, Raffi Enficiaud wrote:
>>> * Why is Matlab_VERSION_STRING cached? Shouldn't it be computed
>>> every time from the matlab that was found?
>>
>> In case the version is not found with an obvious method
>> (on OSX /Applications/MATLABVersion, on Win32, the version also is
>> given by the registry key), we have to find the version of matlab
>> by running matlab itself. I am caching the version once I have it
>> to prevent any further execution of matlab for retrieving this
>> information.
>
> Okay. Currently the value is user-facing, but it shouldn't ever be
> edited manually, right? Instead the detected version could be cached
> in an INTERNAL cache entry. Also there should be a second internal
> entry that records which matlab program was executed to compute the
> version. If the latter does not match then the version should be
> re-computed.
>
>> In case a symlink of the binary called "matlab" exists in /usr/local/bin
>> for instance, I need to retrieve the path of the libraries mex, mx etc,
>> that are relative to the real installation path of matlab.
>
> In that case I think you should look for those pieces relative to
> the original executable location first, and if not found then
> resolve symlinks into a temporary variable name and then use that.
> The resolved path should not be made user-facing so that any user
> that sets Matlab_MAIN_PROGRAM explicitly will see that value
> persist.
>
> 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Dear Brad,
I just tested the patch I sent you on OSX and Win32 and all the tests are clear.
Best,
Raffi Enficiaud
> On 18 Feb 2015, at 01:28, Raffi Enficiaud wrote:
>
> Dear Brad,
>
> Please find attached a patch addressing the issues mentioned in your email.
> The tests were failing because of the following modification:
>
> - matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
> matlab_list_of_all_versions)
> + matlab_get_version_from_matlab_run("${Matlab_MAIN_PROGRAM}"
> matlab_list_of_all_versions)
>
> Apparently the quotes here are interpreted as part of the binary name, which
> prevents the proper call to matlab using the execute_process function.
>
> I kept the symlink resolution, but I narrowed the case those should be
> resolved. I added a variable pointing to the (symlink resolved) location of
> the binary from which the version is retrieved. I compare paths symlink
> resolved for that purpose. I hope this is in line with what you would like to
> have.
>
> Note that I only tested on LinuxLTS14.04 locally, I will test further
> tomorrow morning.
> I also changed the build path of the Windows agent, the build should be clear
> on Windows now.
>
> Best regards,
> Raffi Enficiaud
>
> <0001-Addressing-the-visibility-of-the-internal-variables-.patch>
>> On 13 Feb 2015, at 16:36, Brad King wrote:
>>
>> On 02/13/2015 09:43 AM, Raffi Enficiaud wrote:
* Why is Matlab_VERSION_STRING cached? Shouldn't it be computed
every time from the matlab that was found?
>>>
>>> In case the version is not found with an obvious method
>>> (on OSX /Applications/MATLABVersion, on Win32, the version also is
>>> given by the registry key), we have to find the version of matlab
>>> by running matlab itself. I am caching the version once I have it
>>> to prevent any further execution of matlab for retrieving this
>>> information.
>>
>> Okay. Currently the value is user-facing, but it shouldn't ever be
>> edited manually, right? Instead the detected version could be cached
>> in an INTERNAL cache entry. Also there should be a second internal
>> entry that records which matlab program was executed to compute the
>> version. If the latter does not match then the version should be
>> re-computed.
>>
>>> In case a symlink of the binary called "matlab" exists in /usr/local/bin
>>> for instance, I need to retrieve the path of the libraries mex, mx etc,
>>> that are relative to the real installation path of matlab.
>>
>> In that case I think you should look for those pieces relative to
>> the original executable location first, and if not found then
>> resolve symlinks into a temporary variable name and then use that.
>> The resolved path should not be made user-facing so that any user
>> that sets Matlab_MAIN_PROGRAM explicitly will see that value
>> persist.
>>
>> 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/mailman/listinfo/cmake-developers
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
> The tests were failing because of the following modification:
>
> - matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
> matlab_list_of_all_versions)
> + matlab_get_version_from_matlab_run("${Matlab_MAIN_PROGRAM}"
> matlab_list_of_all_versions)
>
> Apparently the quotes here are interpreted as part of the binary name,
> which prevents the proper call to matlab using the execute_process function.
That should not be possible. The quotes are needed in case the variable
value is an empty string. They will not be treated as part of the value
passed to the function argument.
> I kept the symlink resolution, but I narrowed the case those should be
> resolved. I added a variable pointing to the (symlink resolved) location
> of the binary from which the version is retrieved.
Yes, thanks.
I squashed the changes into 9d414ca2 and rebased again. Everything
so far is now in:
FindMatlab: Rewrite module and provide a usage API
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
and merged to 'next' for testing. Please base fixes for the below
on that.
More comments:
Why do you need so many different find_program calls for matlab?
There should be exactly one for Matlab_MAIN_PROGRAM, and it does
not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
find_program does that already. Any symlink resolution can be
done on the result.
The get_filename_component(PROGRAM) mode is intended to take a
command line string and figure out which leading piece is an
existing program in case it is an unquoted path with spaces.
While it may be a bug that this can return a directory, there
should be no use case for this functionality in FindMatlab.
> # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
> # reg does not work from cmake, curiously, as is. The command provides the
> # desired result under the command line though.
> # Fix: this is because "/reg:64" should appended to the command, otherwise
> # it gets on the 32 bits software key (curiously again)
This is because the default registry view depends on which "reg"
tool gets executed. These comments do not belong in the final
version of the module.
> find_program(MATLAB_REG_EXE_LOCATION "reg")
Many projects just execute_process() the "reg" tool directly
without finding it first. It is reliably available on Windows.
> execute_process(
> COMMAND ${matlab_binary_program} -nosplash -nojvm
> ${_matlab_additional_commands} -logfile
> ${_matlab_temporary_folder}/matlabVersionLog.cmaketmp -nodesktop -nodisplay
> -r "version, exit"
> OUTPUT_VARIABLE _matlab_version_from_cmd_dummy
> RESULT_VARIABLE _matlab_result_version_call
> TIMEOUT 30
> )
This should quote "${matlab_binary_program}" in case it is
empty for some reason. Also you should capture the stderr
output with ERROR_VARIABLE so it does not leak to the output
of the CMake configuration process.
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Please find attached the patch addressing the issues + some others, rebased
against 5dae6cf.
I tested it on the 3 target platforms.
patch.diff
Description: Binary data
> On 18 Feb 2015, at 15:13, Brad King wrote:
>
> On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
>> The tests were failing because of the following modification:
>>
>> - matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
>> matlab_list_of_all_versions)
>> + matlab_get_version_from_matlab_run("${Matlab_MAIN_PROGRAM}"
>> matlab_list_of_all_versions)
>>
>> Apparently the quotes here are interpreted as part of the binary name,
>> which prevents the proper call to matlab using the execute_process function.
>
> That should not be possible. The quotes are needed in case the variable
> value is an empty string. They will not be treated as part of the value
> passed to the function argument.
I restored the quotes. Maybe I experienced a caching issue: I run ctest with
"FindMatlab" regex, and from time to time the cache is messed while I am
working and I do not clean the folders systematically.
>
>> I kept the symlink resolution, but I narrowed the case those should be
>> resolved. I added a variable pointing to the (symlink resolved) location
>> of the binary from which the version is retrieved.
>
> Yes, thanks.
>
> I squashed the changes into 9d414ca2 and rebased again. Everything
> so far is now in:
>
> FindMatlab: Rewrite module and provide a usage API
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
>
> and merged to 'next' for testing. Please base fixes for the below
> on that.
Couple of questions:
- does the script of the dashboard clean the folders? Or I have to do that
manually? (cf caching issues above)
- is it the "next" branch that is tested on the "nightly" section of the
dashboard?
>
> More comments:
>
> Why do you need so many different find_program calls for matlab?
> There should be exactly one for Matlab_MAIN_PROGRAM, and it does
> not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
> find_program does that already. Any symlink resolution can be
> done on the result.
I wanted to separate the parts in some kind of modules.
- The first part is supposed to output the Matlab_ROOT and nothing else, and
the other parts are relying on that. Finding a matlab_program is an
implementation "detail", which is not cross platform. Yet, the method is kind
of robust to find a proper installation ROOT.
- The second part deals with the version, in case we have no other way than
from asking Matlab. Since at this point, we have a ROOT, either given by the
user or from the first part, we search for the matlab program using this
information alone. In case the user gave the ROOT but not the version, we still
have to find the program under this ROOT. In case the user gave nothing, we
have to find the ROOT and the version, the former maybe implying a
matlab_program search. Again, I think this is an implementation detail that the
second part should not rely on.
- The third part is the user facing matlab_program, that we find on demand.
I agree this can be "optimized" in terms of find_program calls, but I would
like to keep this structure for finding in the appropriate sequence all the
information needed by the module.
The symlink resolutions are made on the appropriate places now.
>
> The get_filename_component(PROGRAM) mode is intended to take a
> command line string and figure out which leading piece is an
> existing program in case it is an unquoted path with spaces.
> While it may be a bug that this can return a directory, there
> should be no use case for this functionality in FindMatlab.
I did not understood that from the documentation ("the program in filename will
be found in the system search path"): I thought it was another way of finding
programs. I removed the corresponding lines.
>
>> # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
>> # reg does not work from cmake, curiously, as is. The command provides the
>> # desired result under the command line though.
>> # Fix: this is because "/reg:64" should appended to the command, otherwise
>> # it gets on the 32 bits software key (curiously again)
>
> This is because the default registry view depends on which "reg"
> tool gets executed. These comments do not belong in the final
> version of the module.
Yes, we exchanged on this point already. I removed the comments. Basically, at
some point I thought it would have been useful to use cmake as a make that can
run matlab commands through the matlab_program (and not obliged to link
anything to it). This is not possible in the current state of the module, but
would be possible readily in the future. BTW, I volunteered for the maintenance
of the module, so I guess these would be future extensions.
>
>> find_program(MATLAB_REG_EXE_LOCATION "reg")
>
> Many projects just execute_process() the "reg" tool directly
>
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Dear Brad,
Apparently there are some issues when things are running with the dashboard,
which I did not observed yesterday.
Those issues are related to the space in the test folder in the dashboard,
which I did not see on my local computer.
The attached patch (based on 5dae6cf) should solve those issues (tested only in
the dashboard folder of the ubuntu version).
0001-Fixing-problems-related-to-spaces-in-directory-names.patch
Description: Binary data
Thanks,
Raffi
> On 18 Feb 2015, at 23:11, Raffi Enficiaud wrote:
>
> Please find attached the patch addressing the issues + some others, rebased
> against 5dae6cf.
> I tested it on the 3 target platforms.
>
>
>
>> On 18 Feb 2015, at 15:13, Brad King wrote:
>>
>> On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
>>> The tests were failing because of the following modification:
>>>
>>> - matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
>>> matlab_list_of_all_versions)
>>> + matlab_get_version_from_matlab_run("${Matlab_MAIN_PROGRAM}"
>>> matlab_list_of_all_versions)
>>>
>>> Apparently the quotes here are interpreted as part of the binary name,
>>> which prevents the proper call to matlab using the execute_process function.
>>
>> That should not be possible. The quotes are needed in case the variable
>> value is an empty string. They will not be treated as part of the value
>> passed to the function argument.
>
> I restored the quotes. Maybe I experienced a caching issue: I run ctest with
> "FindMatlab" regex, and from time to time the cache is messed while I am
> working and I do not clean the folders systematically.
>
>
>>
>>> I kept the symlink resolution, but I narrowed the case those should be
>>> resolved. I added a variable pointing to the (symlink resolved) location
>>> of the binary from which the version is retrieved.
>>
>> Yes, thanks.
>>
>> I squashed the changes into 9d414ca2 and rebased again. Everything
>> so far is now in:
>>
>> FindMatlab: Rewrite module and provide a usage API
>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
>>
>> and merged to 'next' for testing. Please base fixes for the below
>> on that.
>
> Couple of questions:
> - does the script of the dashboard clean the folders? Or I have to do that
> manually? (cf caching issues above)
> - is it the "next" branch that is tested on the "nightly" section of the
> dashboard?
>
>>
>> More comments:
>>
>> Why do you need so many different find_program calls for matlab?
>> There should be exactly one for Matlab_MAIN_PROGRAM, and it does
>> not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
>> find_program does that already. Any symlink resolution can be
>> done on the result.
>
> I wanted to separate the parts in some kind of modules.
>
> - The first part is supposed to output the Matlab_ROOT and nothing else, and
> the other parts are relying on that. Finding a matlab_program is an
> implementation "detail", which is not cross platform. Yet, the method is kind
> of robust to find a proper installation ROOT.
>
> - The second part deals with the version, in case we have no other way than
> from asking Matlab. Since at this point, we have a ROOT, either given by the
> user or from the first part, we search for the matlab program using this
> information alone. In case the user gave the ROOT but not the version, we
> still have to find the program under this ROOT. In case the user gave
> nothing, we have to find the ROOT and the version, the former maybe implying
> a matlab_program search. Again, I think this is an implementation detail that
> the second part should not rely on.
>
> - The third part is the user facing matlab_program, that we find on demand.
>
> I agree this can be "optimized" in terms of find_program calls, but I would
> like to keep this structure for finding in the appropriate sequence all the
> information needed by the module.
>
> The symlink resolutions are made on the appropriate places now.
>
>>
>> The get_filename_component(PROGRAM) mode is intended to take a
>> command line string and figure out which leading piece is an
>> existing program in case it is an unquoted path with spaces.
>> While it may be a bug that this can return a directory, there
>> should be no use case for this functionality in FindMatlab.
>
> I did not understood that from the documentation ("the program in filename
> will be found in the system search path"): I thought it was another way of
> finding programs. I removed the corresponding lines.
>
>
>>
>>> # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
>>> # reg does not work from cmake, curiously, as is. The command provides the
>>> # desired result under the command line though.
>>> # Fix: this is because "/reg:64" should appended to the command, otherwise
>>> # it gets on the 32 bits software key (curiously again)
>>
>> This is because the default registry view depends on which "reg"
>> tool gets exe
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Please find attached the merge of the two previous patches, rebased on 5dae6cf.
Thanks,
Raffi Enficiaud
0001-Adding-R2014a.patch
Description: Binary data
> On 19 Feb 2015, at 12:49, Raffi Enficiaud wrote:
>
> Dear Brad,
>
> Apparently there are some issues when things are running with the dashboard,
> which I did not observed yesterday.
> Those issues are related to the space in the test folder in the dashboard,
> which I did not see on my local computer.
>
> The attached patch (based on 5dae6cf) should solve those issues (tested only
> in the dashboard folder of the ubuntu version).
>
> <0001-Fixing-problems-related-to-spaces-in-directory-names.patch>
>
> Thanks,
> Raffi
>
>
>
>> On 18 Feb 2015, at 23:11, Raffi Enficiaud wrote:
>>
>> Please find attached the patch addressing the issues + some others, rebased
>> against 5dae6cf.
>> I tested it on the 3 target platforms.
>>
>>
>>
>>> On 18 Feb 2015, at 15:13, Brad King wrote:
>>>
>>> On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
The tests were failing because of the following modification:
- matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
+ matlab_get_version_from_matlab_run("${Matlab_MAIN_PROGRAM}"
matlab_list_of_all_versions)
Apparently the quotes here are interpreted as part of the binary name,
which prevents the proper call to matlab using the execute_process
function.
>>>
>>> That should not be possible. The quotes are needed in case the variable
>>> value is an empty string. They will not be treated as part of the value
>>> passed to the function argument.
>>
>> I restored the quotes. Maybe I experienced a caching issue: I run ctest with
>> "FindMatlab" regex, and from time to time the cache is messed while I am
>> working and I do not clean the folders systematically.
>>
>>
>>>
I kept the symlink resolution, but I narrowed the case those should be
resolved. I added a variable pointing to the (symlink resolved) location
of the binary from which the version is retrieved.
>>>
>>> Yes, thanks.
>>>
>>> I squashed the changes into 9d414ca2 and rebased again. Everything
>>> so far is now in:
>>>
>>> FindMatlab: Rewrite module and provide a usage API
>>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
>>>
>>> and merged to 'next' for testing. Please base fixes for the below
>>> on that.
>>
>> Couple of questions:
>> - does the script of the dashboard clean the folders? Or I have to do that
>> manually? (cf caching issues above)
>> - is it the "next" branch that is tested on the "nightly" section of the
>> dashboard?
>>
>>>
>>> More comments:
>>>
>>> Why do you need so many different find_program calls for matlab?
>>> There should be exactly one for Matlab_MAIN_PROGRAM, and it does
>>> not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
>>> find_program does that already. Any symlink resolution can be
>>> done on the result.
>>
>> I wanted to separate the parts in some kind of modules.
>>
>> - The first part is supposed to output the Matlab_ROOT and nothing else, and
>> the other parts are relying on that. Finding a matlab_program is an
>> implementation "detail", which is not cross platform. Yet, the method is
>> kind of robust to find a proper installation ROOT.
>>
>> - The second part deals with the version, in case we have no other way than
>> from asking Matlab. Since at this point, we have a ROOT, either given by the
>> user or from the first part, we search for the matlab program using this
>> information alone. In case the user gave the ROOT but not the version, we
>> still have to find the program under this ROOT. In case the user gave
>> nothing, we have to find the ROOT and the version, the former maybe implying
>> a matlab_program search. Again, I think this is an implementation detail
>> that the second part should not rely on.
>>
>> - The third part is the user facing matlab_program, that we find on demand.
>>
>> I agree this can be "optimized" in terms of find_program calls, but I would
>> like to keep this structure for finding in the appropriate sequence all the
>> information needed by the module.
>>
>> The symlink resolutions are made on the appropriate places now.
>>
>>>
>>> The get_filename_component(PROGRAM) mode is intended to take a
>>> command line string and figure out which leading piece is an
>>> existing program in case it is an unquoted path with spaces.
>>> While it may be a bug that this can return a directory, there
>>> should be no use case for this functionality in FindMatlab.
>>
>> I did not understood that from the documentation ("the program in filename
>> will be found in the system search path"): I thought it was another way of
>> finding programs. I removed the corresponding lines.
>>
>>
>>>
# list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
# reg does not work from
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 08:39 AM, Raffi Enficiaud wrote:
> Please find attached the merge of the two previous patches, rebased on
> 5dae6cf.
Applied, thanks:
FindMatlab: Further revisions
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1416d214
>> Those issues are related to the space in the test folder in the dashboard
Quoting of arguments in the cmake language:
http://www.cmake.org/cmake/help/v3.2/manual/cmake-language.7.html#command-arguments
is not necessary to deal with spaces that are not literally written in
the argument. Separation of unquoted arguments after variable evaluation
only happens on ";". However, any unnecessary quoting you added also
won't hurt anything and makes it easier to read anyway.
Returning to a previous comment:
> On 02/18/2015 09:13 AM, Brad King wrote:
>> Why do you need so many different find_program calls for matlab?
>> There should be exactly one for Matlab_MAIN_PROGRAM
I still see four places that try to find "matlab", quoted below.
It looks like you're trying to make Matlab_MAIN_PROGRAM defined
if the MAIN_PROGRAM component was requested.
> find_program(
> _matlab_main_tmp
> NAMES matlab)
>
> if(NOT _matlab_main_tmp)
> execute_process(
> COMMAND "which" matlab
> OUTPUT_VARIABLE _matlab_main_tmp
> ERROR_VARIABLE _matlab_main_tmp_err)
> # the output should be cleaned up
> string(STRIP "${_matlab_main_tmp}" _matlab_main_tmp)
> endif()
If find_program doesn't find it, "which" won't have better luck.
> if(Matlab_MAIN_PROGRAM)
> set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM})
> else()
> find_program(
> _matlab_main_tmp
> matlab
> PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
> DOC "Matlab main program"
> NO_DEFAULT_PATH
> )
> endif()
We should not risk finding the wrong matlab here. See below.
> # todo cleanup with code above
> if(NOT DEFINED Matlab_MAIN_PROGRAM)
> find_program(
> Matlab_MAIN_PROGRAM
> matlab
> PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
> DOC "Matlab main program"
> NO_DEFAULT_PATH
> )
> endif()
This looks like the component-specific search. If we are to present
a component-specific result variable name then it can simply be
populated from the "one true" location found.
If "matlab" is needed to compute information for other components
then finding it should not be optional. There should be a single
find_program(Matlab_EXECUTABLE ...)
whose result is cached and re-used everywhere that "matlab" is
needed. Separate symlink-resolving on it can be done when needed
but does not need to be cached.
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 06:49 AM, Raffi Enficiaud wrote: > Apparently there are some issues when things are running with the dashboard For the Visual Studio build on your Windows machine you have: set(CTEST_BUILD_FLAGS "-j4") which is not a valid msbuild flag. For that you could use set(CTEST_BUILD_FLAGS "-m4") instead. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Ok, I thought this was for the ctest program that accepts -j flag. I will do the change, I am running the build already with all the // flags removed. Thanks, Raffi > On 19 Feb 2015, at 15:17, Brad King wrote: > > On 02/19/2015 06:49 AM, Raffi Enficiaud wrote: >> Apparently there are some issues when things are running with the dashboard > > For the Visual Studio build on your Windows machine you have: > > set(CTEST_BUILD_FLAGS "-j4") > > which is not a valid msbuild flag. For that you could use > > set(CTEST_BUILD_FLAGS "-m4") > > instead. > > 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 19 Feb 2015, at 14:53, Brad King wrote:
>
> On 02/19/2015 08:39 AM, Raffi Enficiaud wrote:
>> Please find attached the merge of the two previous patches, rebased on
>> 5dae6cf.
>
> Applied, thanks:
>
> FindMatlab: Further revisions
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1416d214
>
Thanks.
>>> Those issues are related to the space in the test folder in the dashboard
>
> Quoting of arguments in the cmake language:
>
> http://www.cmake.org/cmake/help/v3.2/manual/cmake-language.7.html#command-arguments
>
> is not necessary to deal with spaces that are not literally written in
> the argument. Separation of unquoted arguments after variable evaluation
> only happens on ";". However, any unnecessary quoting you added also
> won't hurt anything and makes it easier to read anyway.
Good then. Matlab supports not very well spaces in the log file name, I suppose
that if I do
execute_process(COMMAND matlab -logfile "some path with spaces")
this is correctly escaped by cmake.
>
> Returning to a previous comment:
>
>> On 02/18/2015 09:13 AM, Brad King wrote:
>>> Why do you need so many different find_program calls for matlab?
>>> There should be exactly one for Matlab_MAIN_PROGRAM
>
> I still see four places that try to find "matlab", quoted below.
> It looks like you're trying to make Matlab_MAIN_PROGRAM defined
> if the MAIN_PROGRAM component was requested.
Relates to my previous answer on this topic.
>
>> find_program(
>>_matlab_main_tmp
>>NAMES matlab)
>>
>> if(NOT _matlab_main_tmp)
>>execute_process(
>> COMMAND "which" matlab
>> OUTPUT_VARIABLE _matlab_main_tmp
>> ERROR_VARIABLE _matlab_main_tmp_err)
>># the output should be cleaned up
>>string(STRIP "${_matlab_main_tmp}" _matlab_main_tmp)
>> endif()
>
> If find_program doesn't find it, "which" won't have better luck.
Which is also what I thought but this is factually incorrect. I tested that
yesterday on a regular LTS14.04 server. find_program fails while "which matlab"
does not.
>
>> if(Matlab_MAIN_PROGRAM)
>>set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM})
>> else()
>>find_program(
>> _matlab_main_tmp
>> matlab
>> PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
>> DOC "Matlab main program"
>> NO_DEFAULT_PATH
>>)
>> endif()
>
> We should not risk finding the wrong matlab here. See below.
>
>> # todo cleanup with code above
>> if(NOT DEFINED Matlab_MAIN_PROGRAM)
>>find_program(
>> Matlab_MAIN_PROGRAM
>> matlab
>> PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
>> DOC "Matlab main program"
>> NO_DEFAULT_PATH
>>)
>> endif()
>
> This looks like the component-specific search. If we are to present
> a component-specific result variable name then it can simply be
> populated from the "one true" location found.
In the code just above, the "if()" condition is not needed anymore since now
there is no aliasing with the previous searches. I'll fix that.
On Windows, we have the Matlab_ROOT and the version from the registry, so we
need to run find_program there. On OSX, if the previous find_program or which
matlab did not result in anything relevant, we parse the
/Application/MATLAB_xxx folders so we end up with a root and a version without
a main_program, so the find_program above is also needed.
>
> If "matlab" is needed to compute information for other components
> then finding it should not be optional. There should be a single
>
> find_program(Matlab_EXECUTABLE ...)
>
> whose result is cached and re-used everywhere that "matlab" is
> needed. Separate symlink-resolving on it can be done when needed
> but does not need to be cached.
I agree with that, but this behaviour is not consistent across every platforms.
My preference goes to the kind of modular approach currently implemented in the
module, which is:
1- find all possible matlab roots with the tools provided by the system, or
just stick to the user input
2- for each or one of them, find the version if information is lacking
3- return the one that fits best to the find_matlab options
Finding the matlab program from time to time is for me an implementation
detail: examples
- if the user give the Matlab_ROOT, the version is lacking, I then need to find
matlab in the second step.
- if the user gave no input, I need to find Matlab in the first step,
conditionally on the platform, to extract Matlab_ROOT (and not to find matlab
itself). I then run the find_matlab in the second step conditionally on the
platform again. In the third step, I gather all the information I have so far,
which is the intersection for all platforms: MatlabROOT and MatlabVERSION.
- on win32, if there is not user defined Matlab_ROOT, we have the root and
version from the registry, there is only the last component oriented
find_program running, only if required by the user.
Also the main functionality is not performance ori
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 10:20 AM, Raffi Enficiaud wrote: >> If find_program doesn't find it, "which" won't have better luck. > > I tested that yesterday on a regular LTS14.04 server. find_program > fails while "which matlab" does not. Please figure out why find_program fails so we can fix it rather than working around it with "which". The find_program command searches the PATH just like "which" does. Is "matlab" one of those executables with "x" permission but not "r" permission? > Finding the matlab program from time to time is for me an > implementation detail Okay, I just wanted an explanation for why there are so many find_program calls for the same thing. If the design is better that way then so be it. However: > Also the main functionality is not performance oriented. > If I start trying to optimize all those calls, I would have > complicated execution paths. Caching is not about performance. It is about giving the user the opportunity to set the result explicitly when the automatic determination gets an undesired result. There needs to be at least (and ideally exactly) one cache entry that stores the location of matlab. If the user sets it up front then great. If not then we should search and store the result there for the user to accept or edit later. Currently MATLAB_USER_ROOT allows the user to specify up front, but does not serve the second role. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 19 Feb 2015, at 16:48, Brad King wrote: > > On 02/19/2015 10:20 AM, Raffi Enficiaud wrote: >>> If find_program doesn't find it, "which" won't have better luck. >> >> I tested that yesterday on a regular LTS14.04 server. find_program >> fails while "which matlab" does not. > > Please figure out why find_program fails so we can fix it rather > than working around it with "which". The find_program command > searches the PATH just like "which" does. Is "matlab" one of > those executables with "x" permission but not "r" permission? On the system I am working, matlab in the PATH is a symlink with r & x permissions renficiaud@madeira3:~/Code/CMake$ which matlab /usr/bin/matlab renficiaud@madeira3:~/Code/CMake$ ls -al /usr/bin/matlab lrwxrwxrwx 1 root root 24 May 15 2013 /usr/bin/matlab -> /etc/alternatives/matlab renficiaud@madeira3:~/Code/CMake$ ls -al /etc/alternatives/matlab lrwxrwxrwx 1 root root 43 Oct 20 15:32 /etc/alternatives/matlab -> /is/software/matlab/linux/R2014a/bin/matlab renficiaud@madeira3:~/Code/CMake$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games Is there any internal in the find_program to check what conditions are not met? > >> Finding the matlab program from time to time is for me an >> implementation detail > > Okay, I just wanted an explanation for why there are so many > find_program calls for the same thing. If the design is better > that way then so be it. However: > >> Also the main functionality is not performance oriented. >> If I start trying to optimize all those calls, I would have >> complicated execution paths. > > Caching is not about performance. It is about giving the user > the opportunity to set the result explicitly when the automatic > determination gets an undesired result. > > There needs to be at least (and ideally exactly) one cache > entry that stores the location of matlab. If the user sets it > up front then great. If not then we should search and store the > result there for the user to accept or edit later. Currently > MATLAB_USER_ROOT allows the user to specify up front, but does > not serve the second role. > If I understand correctly, you propose to merge the variables MATLAB_USER_ROOT and Matlab_ROOT_DIR, is that correct? Or just drop Matlab_ROOT_DIR from the user view? Best, Raffi -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 11:54 AM, Raffi Enficiaud wrote: > On the system I am working, matlab in the PATH is a symlink with > r & x permissions [snip] > Is there any internal in the find_program to check what conditions > are not met? What are the permissions of the underlying file after resolving the link? The find_program command wants "r" permission, and it always unwraps symlinks. > you propose to merge the variables MATLAB_USER_ROOT and > Matlab_ROOT_DIR, is that correct? Yes. Furthermore, if we can always compute the other information from that value then as little of it should be cached as possible. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 19 Feb 2015, at 18:52, Brad King wrote: > > On 02/19/2015 11:54 AM, Raffi Enficiaud wrote: >> On the system I am working, matlab in the PATH is a symlink with >> r & x permissions > [snip] >> Is there any internal in the find_program to check what conditions >> are not met? > > What are the permissions of the underlying file after resolving > the link? The find_program command wants "r" permission, and it > always unwraps symlinks. If I continue the chain: renficiaud@madeira3:~$ ls -al /etc/alternatives/matlab lrwxrwxrwx 1 root root 43 Oct 20 15:32 /etc/alternatives/matlab -> /is/software/matlab/linux/R2014a/bin/matlab renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab -r-xr-xr-x 1 stark is 55331 Dec 27 2013 /is/software/matlab/linux/R2014a/bin/matlab r permission are definitively there and the user is allowed to run this command. BTW, I cannot see in the documentation that find_program unwraps symlinks. By myself, I explained the observed behaviour as find_program being blind to symlinks. > >> you propose to merge the variables MATLAB_USER_ROOT and >> Matlab_ROOT_DIR, is that correct? > > Yes. Furthermore, if we can always compute the other information > from that value then as little of it should be cached as possible. > Ok, will do then. -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 04:15 PM, Raffi Enficiaud wrote:
> renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab
> -r-xr-xr-x 1 stark is 55331 Dec 27 2013
> /is/software/matlab/linux/R2014a/bin/matlab
>
> r permission are definitively there and the user is allowed to run this
> command.
Hmm. See if you can reproduce it with something simple like:
$ cat test.cmake
find_program(MATLAB NAMES matlab)
message(MATLAB=${MATLAB})
$ cmake -P test.cmake
Then build your own CMake with -DCMAKE_BUILD_TYPE=Debug and run it in
a debugger to track down what goes wrong. Set a breakpoint on
"cmsys::SystemTools::FileExists" to step through the low level checks.
> BTW, I cannot see in the documentation that find_program unwraps symlinks.
I meant that when checking for existence and permissions it uses
something equivalent to "stat" as against "lstat". A broken symlink
is not considered to exist. It certainly doesn't resolve symlinks
in the returned path.
-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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 19 Feb 2015, at 22:24, Brad King wrote:
>
> On 02/19/2015 04:15 PM, Raffi Enficiaud wrote:
>> renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab
>> -r-xr-xr-x 1 stark is 55331 Dec 27 2013
>> /is/software/matlab/linux/R2014a/bin/matlab
>>
>> r permission are definitively there and the user is allowed to run this
>> command.
>
> Hmm. See if you can reproduce it with something simple like:
>
> [snip]
I cannot reproduce with this simple example. However, on next, I did that (line
990):
find_program(
_matlab_main_tmp
NAMES matlab)
message(FATAL_ERROR "is find matlab correct? ${_matlab_main_tmp}")
The error message is
CMake Error at /is/ps2/renficiaud/Code/CMake/Modules/FindMatlab.cmake:993
(message):
is find matlab correct?
Call Stack (most recent call first):
CMakeLists.txt:11 (find_package)
Then I did that:
find_program(
matlab_main_tmp
NAMES matlab)
message(FATAL_ERROR "is find matlab correct? ${matlab_main_tmp}")
and the error message is
CMake Error at /is/ps2/renficiaud/Code/CMake/Modules/FindMatlab.cmake:993
(message):
is find matlab correct? /usr/bin/matlab
Call Stack (most recent call first):
CMakeLists.txt:11 (find_package)
The functionality works then, there is something else with the variable itself.
Some lines before I uses the same variable name
set(_matlab_main_tmp "")
I just unset this variable before the call to the find_program, and now it
works good. Basically the variable is not overwritten, maybe because another
one is created in the cache?
Any hint? Known behaviour?
I'll do the fix and remove the "which matlab" then (so we dropped the # of
"find matlab" from 4 to 2 in one day).
Best,
Raffi
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 04:58 PM, Raffi Enficiaud wrote: > I just unset this variable before the call to the find_program, > and now it works good. Yes, this is expected. If find_program sees that the variable is already set then it assumes the value is correct. The idea is that projects can prevent the find from actually running by doing their own thing to set the variable first. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi Brad, Thanks, I started addressing the issues, hopefully I will finish today. Is it ok if I rebase on 1416d21? Best, Raffi > On 23 Feb 2015, at 18:54, Brad King wrote: > > Hi Raffi, > > Your matlab-enabled nightly builds have been clean for a few days on all > the platforms. I've moved them to the "Nightly Expected" section of the > dashboard. > > Now I'm just waiting on your next updates to the module based on my > comments elsewhere in this thread to proceed with the FindMatlab > topic. > > 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/25/2015 04:11 AM, Raffi Enficiaud wrote: > Is it ok if I rebase on 1416d21? Yes, please. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi Brad, Please find the patch addressing the issues you raised. My local tests are clear on the 3 platforms. I removed the RunCMake test on Linux as now the Matlab_MAIN_PROGRAM is required if MATLAB_USER_ROOT is not specified. In the previous implementation, I used temporary variables to avoid bringing this program to the user. Any feedback welcome, Best, Raffi 0001-Simplified-workflow.patch Description: Binary data > On 25 Feb 2015, at 14:32, Brad King wrote: > > On 02/25/2015 04:11 AM, Raffi Enficiaud wrote: >> Is it ok if I rebase on 1416d21? > > Yes, please. > > 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Quick question: Is it possible to redirect the input stream of execute_process from /dev/null on OSX and Linux ? Right now on these platforms, I need to "reset" my shell. If I run the ctest command with < /dev/null, everything is fine. So my guess is that Matlab is manipulating the console somehow. Thanks, Raffi > On 26 Feb 2015, at 18:02, Raffi Enficiaud wrote: > > Hi Brad, > > Please find the patch addressing the issues you raised. My local tests are > clear on the 3 platforms. > I removed the RunCMake test on Linux as now the Matlab_MAIN_PROGRAM is > required if MATLAB_USER_ROOT is not specified. In the previous > implementation, I used temporary variables to avoid bringing this program to > the user. > > Any feedback welcome, > > Best, > Raffi > > <0001-Simplified-workflow.patch> >> On 25 Feb 2015, at 14:32, Brad King wrote: >> >> On 02/25/2015 04:11 AM, Raffi Enficiaud wrote: >>> Is it ok if I rebase on 1416d21? >> >> Yes, please. >> >> 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/mailman/listinfo/cmake-developers -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/26/2015 12:06 PM, Raffi Enficiaud wrote: > Is it possible to redirect the input stream of execute_process > from /dev/null on OSX and Linux ? Yes: INPUT_FILE /dev/null and on Windows: INPUT_FILE NUL -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Thanks! here is the patch then, replacing the previous one, rebased on 1416d214b3. Best, Raffi 0001-Simplified-workflow.patch Description: Binary data > On 26 Feb 2015, at 18:52, Brad King wrote: > > On 02/26/2015 12:06 PM, Raffi Enficiaud wrote: >> Is it possible to redirect the input stream of execute_process >> from /dev/null on OSX and Linux ? > > Yes: > > INPUT_FILE /dev/null > > and on Windows: > > INPUT_FILE NUL > > -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/26/2015 03:23 PM, Raffi Enficiaud wrote: > Thanks! here is the patch then, replacing the previous one, > rebased on 1416d214b3. Okay. In our earlier discussion: On 02/19/2015 12:52 PM, Brad King wrote: >> you propose to merge the variables MATLAB_USER_ROOT and >> Matlab_ROOT_DIR, is that correct? > Yes. Furthermore, if we can always compute the other information > from that value then as little of it should be cached as possible. We never specified explicitly which name to use. I think it should be Matlab_ROOT_DIR because that makes sense whether the user specified it or not. > I removed the RunCMake test on Linux as now the > Matlab_MAIN_PROGRAM is required if MATLAB_USER_ROOT is not > specified. In the previous implementation, I used temporary > variables to avoid bringing this program to the user. We shouldn't have to disable the test. It can still be an error for the MAIN_PROGRAM component to not be requested. You can separate the name of the cache variable used as the "one" search for "matlab" from the name of the result variable used to provide the MAIN_PROGRAM component. That will be consistent with the view that finding "matlab" is an implementation detail on some platforms even when the MAIN_PROGRAM component is not requested. Please revise this patch further for the above. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Le 26/02/15 21:32, Brad King a écrit : On 02/26/2015 03:23 PM, Raffi Enficiaud wrote: We never specified explicitly which name to use. I think it should be Matlab_ROOT_DIR because that makes sense whether the user specified it or not. Right, so I made the changes and updated the documentation. A kind person tested my module and proposed to change the behaviour in order to be able to change the Matlab_ROOT_DIR after the first configuration The workflow would be: - I start without Matlab_ROOT_DIR, - Matlab_ROOT_DIR is automatically determined, - I change Matlab_ROOT_DIR I am expecting all dependent variables (cached or not) be updated to reflect this change. Apparently this is something that is done in eg. wxWidget. The question is: should also this be implemented? The way I am seeing this is to clear all variables when another Matlab_ROOT_DIR than the cached/internal one is set. We shouldn't have to disable the test. It can still be an error for the MAIN_PROGRAM component to not be requested. You can separate the name of the cache variable used as the "one" search for "matlab" from the name of the result variable used to provide the MAIN_PROGRAM component. That will be consistent with the view that finding "matlab" is an implementation detail on some platforms even when the MAIN_PROGRAM component is not requested. Please revise this patch further for the above. Will do. Another question: may the test be dependent on a particular site? For instance, on one of the builders, I have several versions of Matlab. Is testing against the current build site something that would be acceptable? Best, Raffi -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 03/10/2015 09:08 AM, Raffi Enficiaud wrote: > - I change Matlab_ROOT_DIR > > I am expecting all dependent variables (cached or not) be updated > > The question is: should also this be implemented? Yes. See the FindBoost module for similar behavior with respect to the library directory. > Will do. Another question: may the test be dependent on a particular > site? For instance, on one of the builders, I have several versions of > Matlab. Is testing against the current build site something that would > be acceptable? The per-site information should not be hard-coded in the source tree. However, you can use cache entries to hold the local configuration. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Le 10/03/15 14:34, Brad King a écrit : On 03/10/2015 09:08 AM, Raffi Enficiaud wrote: - I change Matlab_ROOT_DIR I am expecting all dependent variables (cached or not) be updated The question is: should also this be implemented? Yes. See the FindBoost module for similar behavior with respect to the library directory. Will do. Another question: may the test be dependent on a particular site? For instance, on one of the builders, I have several versions of Matlab. Is testing against the current build site something that would be acceptable? The per-site information should not be hard-coded in the source tree. However, you can use cache entries to hold the local configuration. -Brad Hi Brad, Please find the attached patch addressing the issues. In the current implementation, if the Matlab_ROOT_DIR is changed by the user, the cached variables are all cleared. Also, Matlab_ROOT_DIR is now the only variable that is seen as non advanced. Best, Raffi >From 4f73bd38849a67ef4e677e223fbb43af9d09f976 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Wed, 11 Mar 2015 00:08:42 +0100 Subject: [PATCH] * Simplified workflow, better isolation of the code when Matlab is to be found from the PATH * Removing the "which matlab" as the find_program was erroneous * MATLAB_USER_ROOT renamed to Matlab_ROOT_DIR, which now reflects the found root, removed Matlab_ROOT * Reduced the number of find_program(matlab) * Nulled the input stream of the execute_process in order to avoid the troubleshooting with the terminal * Clearing all the cached variables in case the Matlab_ROOT_DIR is changed by the user * Marking all but Matlab_ROOT_DIR variable as advanced * Hiding all internal cache entries * Avoiding the computation of the version (Matlab_ROOT_DIR set) if the first pass produced the version automatically --- Modules/FindMatlab.cmake | 487 - Modules/MatlabTestsRedirect.cmake | 8 + Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m | 3 +- Tests/RunCMake/CMakeLists.txt | 1 + 4 files changed, 286 insertions(+), 213 deletions(-) diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake index 9686a76..c637df4 100644 --- a/Modules/FindMatlab.cmake +++ b/Modules/FindMatlab.cmake @@ -28,14 +28,15 @@ # :command:`matlab_get_release_name_from_version` allow a mapping # from the release name to the version. # -# The variable :variable:`MATLAB_USER_ROOT` may be specified in order to give +# The variable :variable:`Matlab_ROOT_DIR` may be specified in order to give # the path of the desired Matlab version. Otherwise, the behaviour is platform # specific: # # * Windows: The installed versions of Matlab are retrieved from the # Windows registry # * OS X: The installed versions of Matlab are given by the MATLAB -# paths in ``/Application`` +# paths in ``/Application``. If no such application is found, it falls back +# to the one that might be accessible from the PATH. # * Unix: The desired Matlab should be accessible from the PATH. # # Additional information is provided when :variable:`MATLAB_FIND_DEBUG` is set. @@ -59,7 +60,7 @@ # Users or projects may set the following variables to configure the module # behaviour: # -# :variable:`MATLAB_USER_ROOT` +# :variable:`Matlab_ROOT_DIR` # the root of the Matlab installation. # :variable:`MATLAB_FIND_DEBUG` # outputs debug information @@ -77,14 +78,15 @@ # ``TRUE`` if the Matlab installation is found, ``FALSE`` # otherwise. All variable below are defined if Matlab is found. # ``Matlab_ROOT_DIR`` -# the root of the Matlab installation determined by the FindMatlab module. +# the final root of the Matlab installation determined by the FindMatlab +# module. # ``Matlab_MAIN_PROGRAM`` # the Matlab binary program. Available only if the component ``MAIN_PROGRAM`` # is given in the :command:`find_package` directive. # ``Matlab_INCLUDE_DIRS`` # the path of the Matlab libraries headers # ``Matlab_MEX_LIBRARY`` -# library for mex +# library for mex, always available. # ``Matlab_MX_LIBRARY`` # mx library of Matlab (arrays). Available only if the component # ``MX_LIBRARY`` has been requested. @@ -102,6 +104,9 @@ # # ``Matlab_MEX_EXTENSION`` # the extension of the mex files for the current platform (given by Matlab). +# ``Matlab_ROOT_DIR`` +# the location of the root of the Matlab installation found. If this value +# is changed by the user, the result variables are recomputed. # # Provided macros # --- @@ -162,10 +167,11 @@ # Reference # -- # -# .. variable:: MATLAB_USER_ROOT +# .. variable:: Matlab_ROOT_DIR # -#The root folder of the Matlab installation. This is set before the call to -#:command:`find_package`. If not set, then an automatic search of Matlab +#The root folder of the Matlab installation. If set before the call to +#:command:`find_package`, the mod
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Le 11/03/15 00:12, Raffi Enficiaud a écrit : Hi Brad, Please find the attached patch addressing the issues. In the current implementation, if the Matlab_ROOT_DIR is changed by the user, the cached variables are all cleared. Also, Matlab_ROOT_DIR is now the only variable that is seen as non advanced. Best, Raffi Hi Brad, The attached patch replaces the previous one: now the versions on Windows are ordered starting the most recent (+ an ugly remaining FATAL_ERROR debug). Best, Raffi >From bca63b3669366d3d2db4438efe91c58d3a82fc40 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Thu, 12 Mar 2015 17:08:44 +0100 Subject: [PATCH] * Simplified workflow, better isolation of the code when Matlab is to be found from the PATH * Removing the "which matlab" as the find_program was erroneous * MATLAB_USER_ROOT renamed to Matlab_ROOT_DIR, which now reflects the found root, removed Matlab_ROOT * Reduced the number of find_program(matlab) * Nulled the input stream of the execute_process in order to avoid the troubleshooting with the terminal * Clearing all the cached variables in case the Matlab_ROOT_DIR is changed by the user * Marking all but Matlab_ROOT_DIR variable as advanced * Hiding all internal cache entries * Avoiding the computation of the version (Matlab_ROOT_DIR set) if the first pass produced the version automatically * Windows: now versions are ordered starting from the most recent --- Modules/FindMatlab.cmake | 490 - Modules/MatlabTestsRedirect.cmake | 8 + Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m | 3 +- Tests/RunCMake/CMakeLists.txt | 1 + 4 files changed, 289 insertions(+), 213 deletions(-) diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake index 9686a76..b61c620 100644 --- a/Modules/FindMatlab.cmake +++ b/Modules/FindMatlab.cmake @@ -28,14 +28,15 @@ # :command:`matlab_get_release_name_from_version` allow a mapping # from the release name to the version. # -# The variable :variable:`MATLAB_USER_ROOT` may be specified in order to give +# The variable :variable:`Matlab_ROOT_DIR` may be specified in order to give # the path of the desired Matlab version. Otherwise, the behaviour is platform # specific: # # * Windows: The installed versions of Matlab are retrieved from the # Windows registry # * OS X: The installed versions of Matlab are given by the MATLAB -# paths in ``/Application`` +# paths in ``/Application``. If no such application is found, it falls back +# to the one that might be accessible from the PATH. # * Unix: The desired Matlab should be accessible from the PATH. # # Additional information is provided when :variable:`MATLAB_FIND_DEBUG` is set. @@ -59,7 +60,7 @@ # Users or projects may set the following variables to configure the module # behaviour: # -# :variable:`MATLAB_USER_ROOT` +# :variable:`Matlab_ROOT_DIR` # the root of the Matlab installation. # :variable:`MATLAB_FIND_DEBUG` # outputs debug information @@ -77,14 +78,15 @@ # ``TRUE`` if the Matlab installation is found, ``FALSE`` # otherwise. All variable below are defined if Matlab is found. # ``Matlab_ROOT_DIR`` -# the root of the Matlab installation determined by the FindMatlab module. +# the final root of the Matlab installation determined by the FindMatlab +# module. # ``Matlab_MAIN_PROGRAM`` # the Matlab binary program. Available only if the component ``MAIN_PROGRAM`` # is given in the :command:`find_package` directive. # ``Matlab_INCLUDE_DIRS`` # the path of the Matlab libraries headers # ``Matlab_MEX_LIBRARY`` -# library for mex +# library for mex, always available. # ``Matlab_MX_LIBRARY`` # mx library of Matlab (arrays). Available only if the component # ``MX_LIBRARY`` has been requested. @@ -102,6 +104,9 @@ # # ``Matlab_MEX_EXTENSION`` # the extension of the mex files for the current platform (given by Matlab). +# ``Matlab_ROOT_DIR`` +# the location of the root of the Matlab installation found. If this value +# is changed by the user, the result variables are recomputed. # # Provided macros # --- @@ -162,10 +167,11 @@ # Reference # -- # -# .. variable:: MATLAB_USER_ROOT +# .. variable:: Matlab_ROOT_DIR # -#The root folder of the Matlab installation. This is set before the call to -#:command:`find_package`. If not set, then an automatic search of Matlab +#The root folder of the Matlab installation. If set before the call to +#:command:`find_package`, the module will look for the components in that +#path. If not set, then an automatic search of Matlab #will be performed. If set, it should point to a valid version of Matlab. # # .. variable:: MATLAB_FIND_DEBUG @@ -176,7 +182,6 @@ # .. variable:: MATLAB_ADDITIONAL_VERSIONS # # If set, specifies additional versions of Matlab that may be looked for. -# This variable will be used if :variable:`MATLA
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 03/12/2015 12:35 PM, Raffi Enficiaud wrote: >> Please find the attached patch addressing the issues. In the current >> implementation, if the Matlab_ROOT_DIR is changed by the user, the >> cached variables are all cleared. >> Also, Matlab_ROOT_DIR is now the only variable that is seen as non >> advanced. > > The attached patch replaces the previous one: now the versions on > Windows are ordered starting the most recent (+ an ugly remaining > FATAL_ERROR debug). Great. I applied that on top of where we last left off and then rebased on 'master' to resolve conflicts. I also made a couple minor tweaks: * Renamed one more MATLAB_USER_ROOT => Matlab_ROOT_DIR * Do not call list(REMOVE_DUPLICATES/SORT/REVERSE) with no list The commits are now: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c025a5f FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=842ab109 FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3743aa11 I will squash all this together once everything is done. For now please base further work on commit 3743aa11. We'll see how this does on the nightly testing! 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Le 12/03/15 21:00, Brad King a écrit : On 03/12/2015 12:35 PM, Raffi Enficiaud wrote: * Renamed one more MATLAB_USER_ROOT => Matlab_ROOT_DIR * Do not call list(REMOVE_DUPLICATES/SORT/REVERSE) with no list Thanks! The commits are now: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c025a5f FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=842ab109 FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3743aa11 I will squash all this together once everything is done. For now please base further work on commit 3743aa11. We'll see how this does on the nightly testing! A test is failing on win32 but I to not think it is due to the FindMatlab: https://open.cdash.org/testDetails.php?test=319823202&build=3731585 What other changes are needed? Best, Raffi -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Le 12/03/15 21:00, Brad King a écrit :
On 03/12/2015 12:35 PM, Raffi Enficiaud wrote:
I will squash all this together once everything is done.
For now please base further work on commit 3743aa11.
We'll see how this does on the nightly testing!
Hi,
I have a problem running the tests on win7. All the tests are passing,
but at the end, I have the following:
17-Mar-2015 04:23:23100% tests passed, 0 tests failed out of 21
17-Mar-2015 04:23:23
17-Mar-2015 04:23:23Total Test time (real) = 21.84 sec
17-Mar-2015 04:23:23 Add file:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake
17-Mar-2015 04:23:23 Add file:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/cmake_common.cmake
17-Mar-2015 04:23:23 Add file:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake
17-Mar-2015 04:23:23 Add file:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/kwsys_common.cmake
17-Mar-2015 04:23:23Submit files (using http)
17-Mar-2015 04:23:23 Using HTTP submit method
17-Mar-2015 04:23:23 Drop
site:http://open.cdash.org/submit.php?project=KWSys
17-Mar-2015 04:23:40 Uploaded:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My
Tests/KWSys-build/Testing/20150317-0100/Build.xml
17-Mar-2015 04:23:44 Uploaded:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My
Tests/KWSys-build/Testing/20150317-0100/Configure.xml
17-Mar-2015 04:23:49 Uploaded:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My
Tests/KWSys-build/Testing/20150317-0100/Notes.xml
17-Mar-2015 04:23:53 Uploaded:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My
Tests/KWSys-build/Testing/20150317-0100/Test.xml
17-Mar-2015 04:23:56 Uploaded:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My
Tests/KWSys-build/Testing/20150317-0100/Update.xml
17-Mar-2015 04:23:56 Submission successful
17-Mar-2015 04:23:57 Error in read script:
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake
17-Mar-2015 04:23:57 Failing task since return code of [C:\Program
Files (x86)\CMake 2.8\bin\ctest.exe -S findmatlab_nightbuild.cmake -V]
was -1 while expected 0
The content of the findmatlab_nightbuild.cmake is
set(CTEST_SITE "bambooagent.raffienficiaud")
set(CTEST_BUILD_NAME "Win7x64-vs2013e-matlab2013b")
set(CTEST_BUILD_CONFIGURATION Debug)
set(CTEST_CMAKE_GENERATOR "Visual Studio 12 Win64")
set(dashboard_cache "CMake_TEST_FindMatlab:BOOL=ON")
include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake)
and I am using ctest 2.8.12 to run -S findmatlab_nightbuild.cmake -V
Any clue?
Raffi
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 03/16/2015 05:58 PM, Raffi Enficiaud wrote: > Le 12/03/15 21:00, Brad King a écrit : >> I will squash all this together once everything is done. >> For now please base further work on commit 3743aa11. >> We'll see how this does on the nightly testing! > > A test is failing on win32 but I to not think it is due to the FindMatlab: That was a new test that failed on many machines its first day. It has now been resolved. > What other changes are needed? Nothing right now! I've squashed this all into one commit: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49c8dcf7 and merged to 'master' for inclusion in 3.3. Thanks for all your work on this and persistence with following up on feedback. This is a huge improvement over the previous FindMatlab module. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 17 Mar 2015, at 16:25, Brad King wrote: > > Nothing right now! I've squashed this all into one commit: > > FindMatlab: Rewrite module and provide a usage API > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49c8dcf7 > > and merged to 'master' for inclusion in 3.3. > > Thanks for all your work on this and persistence with following up > on feedback. This is a huge improvement over the previous FindMatlab > module. > > -Brad I am happy that it worked! I think everything in http://www.cmake.org/Bug/view.php?id=14641 was addressed. What should the "maintainer" usually do? Best, Raffi -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 03/17/2015 12:28 PM, Raffi Enficiaud wrote: > I think everything in http://www.cmake.org/Bug/view.php?id=14641 was > addressed. > What should the "maintainer" usually do? I've marked your Mantis account as a developer for CMake and assigned the issue to you. In this case since it's already resolved I went ahead and marked the issue as such already. Future issues with this module may be assigned to you. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
> On 17 Mar 2015, at 19:39, Brad King wrote: > > On 03/17/2015 12:28 PM, Raffi Enficiaud wrote: >> I think everything in http://www.cmake.org/Bug/view.php?id=14641 was >> addressed. >> What should the "maintainer" usually do? > > I've marked your Mantis account as a developer for CMake and assigned > the issue to you. In this case since it's already resolved I went ahead > and marked the issue as such already. Future issues with this module may > be assigned to you. > > Thanks, > -Brad > Very good, and many thanks for your support, Best, Raffi -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 03/05/2014 08:49 AM, Raffi Enficiaud wrote: > I am volunteering myself for maintaining the Matlab package. Great, thanks! > I already gave some of the functionalities in the following mantis ticket: > http://www.cmake.org/Bug/view.php?id=14641 In answer to your questions from there: > - What should I do now? > - What is the release process? Posting here was a good first step. See full instructions here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer Please post the proposed module as an attachment here for discussion and review. Once things are in good shape then we will ask you to sign up for Git access. > - If I release this script with the BSD-3 license, it is ok right? > What about the Boost v1 license that I am currently using? We require the BSD 3-Clause license, please. The developer manual: http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#find-modules specifies the exact format in which the legal notice must appear. The test suite verifies it. > - How to update the documentation then? Should the package be > released with a text file documenting the functionalities? The documentation goes in the module as described here: http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#module-documentation Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi, 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. FindMatlab.cmake Description: Binary data From what I see in the instructions, there are some issues with the proposed module: - 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? - 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. What are the good practices for these variables ? - some of the variables should be renamed - the version matching should be performed in the module, right ? Best, Raffi Enficiaud On 05 Mar 2014, at 18:50, Brad King wrote: > On 03/05/2014 08:49 AM, Raffi Enficiaud wrote: >> I am volunteering myself for maintaining the Matlab package. > > Great, thanks! > >> I already gave some of the functionalities in the following mantis ticket: >> http://www.cmake.org/Bug/view.php?id=14641 > > In answer to your questions from there: > >> - What should I do now? >> - What is the release process? > > Posting here was a good first step. See full instructions here: > > http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer > > Please post the proposed module as an attachment here for discussion > and review. Once things are in good shape then we will ask you to > sign up for Git access. > >> - If I release this script with the BSD-3 license, it is ok right? >> What about the Boost v1 license that I am currently using? > > We require the BSD 3-Clause license, please. The developer manual: > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#find-modules > > specifies the exact format in which the legal notice must appear. > The test suite verifies it. > >> - How to update the documentation then? Should the package be >> released with a text file documenting the functionalities? > > The documentation goes in the module as described here: > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#module-documentation > > Thanks, > -Brad > -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
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 _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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
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('$',
'${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 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 _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
> func
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 04/09/2014 05:09 PM, Raffi Enficiaud wrote:
> 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
Thanks. I'll take another look through the module when I get a chance.
You should be able to make further progress with the comments below.
> 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.
If it is going to be added upstream it needs to have the appropriate
documentation syntax. You can still use comment blocks starting in
'#' on every line as most modules currently do and it will work with
2.8.12.
> 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.
Many of our tests use "cmake -P" to run a cmake script that performs
the test inside. You can use -Dvar=${val} before the -P option to
pass options to the script, such as $.
> - Is it ok if we create log files of leave them onto the disk?
Yes, but they should be inside the CMake build tree so there are
no side effects left when the tree is removed.
> two modes for querying the registry: x86 and x64 modes.
> This is not very clear to me what I should do on that:
The find_library command expands registry values with the view
that matches the target architecture. The find_program command
looks at the matching architecture first and then the other one:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v3.0.0-rc3#l347
This is how most of the modules deal with the difference. I'm
not familiar enough with matlab to say what should be done here.
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
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi,
Sorry for the delayed answer.
On 11 Apr 2014, at 15:35, Brad King wrote:
>> 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.
>
> If it is going to be added upstream it needs to have the appropriate
> documentation syntax. You can still use comment blocks starting in
> '#' on every line as most modules currently do and it will work with
> 2.8.12.
Sorry for the misunderstanding. It does use SPHINX syntax. I was mentioning the
fact that I cannot use block comments like
#[[.rst:
.. command:: xxx_do_something
#]]
because it is not compatible with cmake 2.8. All doc lines are prefixed with #
instead.
>
>> 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.
>
> Many of our tests use "cmake -P" to run a cmake script that performs
> the test inside. You can use -Dvar=${val} before the -P option to
> pass options to the script, such as $.
Done: this is the add_matlab_unit_test function. In fact, I think I can remove
the log files since they are redundant with the tests logs. What do you think?
>
>> - Is it ok if we create log files of leave them onto the disk?
>
> Yes, but they should be inside the CMake build tree so there are
> no side effects left when the tree is removed.
Cool. This is what it does.
>
>> two modes for querying the registry: x86 and x64 modes.
>> This is not very clear to me what I should do on that:
>
> The find_library command expands registry values with the view
> that matches the target architecture. The find_program command
> looks at the matching architecture first and then the other one:
>
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v3.0.0-rc3#l347
>
> This is how most of the modules deal with the difference. I'm
> not familiar enough with matlab to say what should be done here.
Well, this is not exactly what I am doing in fact with this module. I query the
registry for all entries below a specific registry key, instead of brute-force
checking all the possible keys.
Now I am using CMAKE_CL_64 for switching the query on the x86 or x64 mode.
> Thanks,
> -Brad
>
I added a function add_matlab_mex that is like a add_library for creating MEX
(compiled) extensions. There is an option to this function called
REDUCE_VISIBILITY which deals with symbols collision between the library
shipped with Matlab and the one the MEX file links to (Unix only). Basically,
with this option on, all symbols of the MEX file are hidden, which is more or
less what is happening on Windows.
I attach to this email the updated files.
FindMatlab_TestsRedirect.cmake
Description: Binary data
FindMatlab.cmake
Description: Binary data
So far I am not sure how my implementation is compatible with the previous
FindMatlab package. The requirements are to define the same variables, right?
Is there anything else?
BTW, is there any variable that tells the current cmake list, even in function
in packages? The add_matlab_unittest is a function calling
FindMatlab_TestsRedirect.cmake in script mode. When I use
CMAKE_CURRENT_LIST_DIR, it takes the value of the cmake file calling the
function. I would like to reference the call to FindMatlab_TestsRedirect.cmake
relatively to FindMatlab.cmake.
Best,
Raffi
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi Raffi,
Thanks for your continuing work on this module.
I've made some whitespace and quoting tweaks to the files. See attached
updated versions. I also renamed the test helper to not start in "Find"
since no one should call find_package(Matlab_TestsRedirect). See further
comments below.
On 07/04/2014 08:02 PM, Raffi Enficiaud wrote:
>> Many of our tests use "cmake -P" to run a cmake script that performs
>> the test inside. You can use -Dvar=${val} before the -P option to
>> pass options to the script, such as $.
>
> Done: this is the add_matlab_unit_test function. In fact, I think I can
> remove the log files since they are redundant with the tests logs.
I see no problem with that, but I'm not familiar with the tools.
> I added a function add_matlab_mex that is like a add_library
Please make all APIs start in "matlab_".
The documentation blocks for each command also need to start in "#.rst:"
#.rst:
# .. command:: add_matlab_mex
or they will not be included in the processed documentation.
> for creating MEX (compiled) extensions. There is an option to this
> function called REDUCE_VISIBILITY
I see that implemented here:
> if(HAS_VISIBILITY_INLINE_HIDDEN)
> target_compile_options(${${prefix}_NAME} PRIVATE
> "-fvisibility-inlines-hidden")
> endif()
> if(HAS_VISIBILITY_HIDDEN)
> target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility=hidden")
> endif()
An upstream version of the module should use the builtin features
for visibility settings:
http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.html
http://www.cmake.org/cmake/help/v3.0/prop_tgt/VISIBILITY_INLINES_HIDDEN.html
> #set(MATLAB_ADDITIONAL_VERSIONS
> # "release_name1" "corresponding_version1"
> # "release_name2" "corresponding_version2"
> # ...
> # )
Rather than relying on matched pairs, perhaps use "=" to separate:
#set(MATLAB_ADDITIONAL_VERSIONS
# "release_name1=corresponding_version1"
# "release_name2=corresponding_version2"
?
> I am not sure how my implementation is compatible with the previous
> FindMatlab package. The requirements are to define the same variables,
> right? Is there anything else?
It needs to produce the same result variables and also respond to
the old "input" variables (like find_ command cached results) that
the old module did. That way existing build scripts can continue
to work.
> +# * ``MATLAB_USER_ROOT`` the root of the Matlab installation. This is given
> by the user.
This should be documented in its own section of variables that the
user can set to control the search. See FindZLIB for example.
> + # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call
> to reg does not work
> + # from cmake, curiously, as is. The command provides the desired result
> under the command line though.
> + # Fix: this is because "/reg:64" should appended to the command, otherwise
> it gets on the 32 bits software key (curiously again)
This is because it gets the registry view of the calling CMake
unless you tell it what view to use.
> + find_program(MATLAB_REG_EXE_LOCATION "reg")
> + file(TO_NATIVE_PATH ${MATLAB_REG_EXE_LOCATION} MATLAB_REG_EXE_LOCATION)
The second line should not be needed. The execute_process command
will take care of the path format.
> + if((NOT DEFINED MATLAB_USER_ROOT) OR (NOT MATLAB_USER_ROOT))
This can be shortened to
if(NOT MATLAB_USER_ROOT)
> +if(NOT ${Matlab_PROGRAM})
and this to
if(NOT Matlab_PROGRAM)
> BTW, is there any variable that tells the current cmake list,
> even in function in packages?
In the attached version I added
set(_FindMatlab_SELF_DIR "${CMAKE_CURRENT_LIST_DIR}")
to the top of the file to save the location of the file for re-use
inside function calls later.
Thanks,
-Brad
# Usage: cmake
# -Dtest_timeout=180
# -Dworking_directory="."
# -Doutput_directory=
# -Dadditional_paths=""
# -DMatlab_PROGRAM=matlab_exe_location
# -DMatlab_ADDITIONNAL_STARTUP_OPTIONS=""
# -Dtest_name=name_of_the_test
# -Dunittest_file_to_run
# -P FindMatlab_TestsRedirect.cmake
set(Matlab_UNIT_TESTS_CMD -nosplash -nojvm -nodesktop -nodisplay ${Matlab_ADDITIONNAL_STARTUP_OPTIONS})
if(WIN32)
set(Matlab_UNIT_TESTS_CMD ${Matlab_UNIT_TESTS_CMD} -wait)
endif()
if(NOT test_timeout)
set(test_timeout 180)
endif()
get_filename_component(unittest_file_directory "${unittest_file_to_run}" DIRECTORY)
get_filename_component(unittest_file_to_run_name "${unittest_file_to_run}" NAME_WE)
set(concat_string '${unittest_file_directory}')
foreach(s IN LISTS additional_paths)
if(NOT "${s}" STREQUAL "")
set(concat_string "${concat_string}, '${s}'")
endif()
endforeach()
set(Matlab_SCRIPT_TO_RUN
"addpath(${concat_string})\; path, runtests('${unittest_file_to_run_name}'), exit(max([ans(1,:).Failed]))"
)
set(Matlab_LOG_FILE ${output_directory}/${test_name}.log)
execute_process(
COMMAND ${Matlab_PROGRAM} ${Matlab_UNIT_TESTS_CMD} -logfile ${Mat
