Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 17 Mar 2015, at 19:39, Brad King brad.k...@kitware.com 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
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/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 16:25, Brad King brad.k...@kitware.com 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
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=319823202build=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 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 raffi.enfici...@tuebingen.mpg.de 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
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 raffi.enfici...@tuebingen.mpg.de 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 +#
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 raffi.enfici...@free.fr 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 brad.k...@kitware.com 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
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 brad.k...@kitware.com 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
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 brad.k...@kitware.com 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/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, 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 brad.k...@kitware.com 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/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
On 19 Feb 2015, at 18:52, Brad King brad.k...@kitware.com 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
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 raffi.enfici...@free.fr 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 raffi.enfici...@free.fr wrote:
Please find attached the patch addressing the issues + some others, rebased
against 5dae6cf.
I tested it on the 3 target platforms.
patch.diff
On 18 Feb 2015, at 15:13, Brad King brad.k...@kitware.com 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
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 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
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 brad.k...@kitware.com 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 brad.k...@kitware.com 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 oriented. Caching is in fact an
undesirable side-effect for what I want to achieve. While finding matlab is
certainly not optimal,
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 19 Feb 2015, at 22:24, Brad King brad.k...@kitware.com 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: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 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 16:48, Brad King brad.k...@kitware.com 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
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 raffi.enfici...@free.fr 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 brad.k...@kitware.com 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
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 brad.k...@kitware.com 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
without finding it first. It is reliably available on Windows.
Ok, I made
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
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 brad.k...@kitware.com 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 brad.k...@kitware.com 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
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=11851project=1currenttime=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 raffi.enfici...@free.fr wrote: On 12 Feb 2015, at 19:03, Brad King brad.k...@kitware.com 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 13 Feb 2015, at 14:58, Brad King brad.k...@kitware.com 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=11851project=1currenttime=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/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=11851project=1currenttime=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
Hi,
My comments below:
On 13 Feb 2015, at 15:33, Brad King brad.k...@kitware.com 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 brad.k...@kitware.com 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/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 brad.k...@kitware.com 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
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/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
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 raffi.enfici...@free.fr 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
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 brad.k...@kitware.com 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 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 brad.k...@kitware.com 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/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
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 brad.k...@kitware.com 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
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 brad.k...@kitware.com 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/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 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 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 $TARGET_FILE_DIR:my_mex_target.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 FindMatlab2 ?+# *
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 $TARGET_FILE_DIR:my_mex_target.
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 ${Matlab_LOG_FILE} -r ${Matlab_SCRIPT_TO_RUN}
RESULT_VARIABLE res
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 brad.k...@kitware.com 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 $TARGET_FILE_DIR:my_mex_target.
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
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 $TARGET_FILE_DIR:my_mex_target.
- 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 all,
After Brad’s feedbacks, I did the following:
- fix + clean the documentation
- remove any unwanted message, added a variable in order to print diagnostic
- cleaned variable/function names
- changed macros to function
- added components: mex compiler, eng/mx libraries, matlab program
- proper version testing
- making use of FindPackageHandleStandardArgs for the version + components +
variables
The doc runs ok. I avoided using the new syntax of cmake 3.x because I am still
using 2.8.12, and I also would like ppl to get this new package and run it on
older versions.
The set of variables that are defined in this implementation is a superset of
the current package. So it meets your definition of compatible. However, I do
not have older versions of Matlab available, so I cannot say for sure it should
work with any currently supported installation.
What remains is mainly the unit test functions. Currently, what I do is this,
and this works:
add_test(NAME matlabtest-1
COMMAND ${MATLAB_PROGRAM} ${MATLAB_UNIT_TESTS_CMD} -logfile
${CMAKE_BINARY_DIR}/matlabtest_1.log
-r addpath('$TARGET_FILE_DIR:my_mex_target',
'${CMAKE_SOURCE_DIR}/test', '${Boost_LIBRARY_DIRS}'); path,
runtests('matlab_unit_tests'), exit(max([ans(1,:).Failed])))
set_tests_properties(matlabtest-1 PROPERTIES TIMEOUT 30)
where MATLAB_UNIT_TESTS_CMD is a set of platform specific options for launching
Matlab.
While the solution is not very elegant, it provides the results expected. The
reason why I do not find this elegant is that the real output of Matlab goes to
a log file. This is needed because on windows, it is impossible to get the
output otherwise (the instance is running in another window).
- Do you have by chance a mean to address that? like a post-test function that
is alway ran after a test? That way, the log file may be consumed directly by
the test framework in order to have the output in the test logs. The current
solution I am seeing now is to do a test on a cmake script that does the job of
launching the command and flushing the log file onto the console.
- Is it ok if we create log files of leave them onto the disk? Maybe in a
Matlab directory? This might be advantageous: eg. some continuous build server
may parse them in order to create junit files
Another question I have is for Windows. The module looks into the registry for
Matlab installations. However, there are two modes for querying the registry:
x86 and x64 modes. This is not very clear to me what I should do on that:
for instance, having a generator WIN64 does not mean that we should have Matlab
WIN64: the user might be interested in just running Matlab and not linking to
the Matlab libraries.
There should be some other modules that have this problem I think. What would
be the best strategy to separate the notions of binary that can be run on
several architecture, from the notion of thirdparty artifacts needed to
construct the project? Python for instance separates the libraries from the
interpreter.
I hope this goes to the right direction!
Best,
Raffi
FindMatlab.cmake
Description: Binary data
On 06 Mar 2014, at 17:52, Brad King brad.k...@kitware.com wrote:
On 03/05/2014 05:46 PM, Raffi Enficiaud wrote:
So, I began writing the doc of the module and changed the license
according to the instructions. I am attaching the module to the email.
Thanks!
The documentation so far is a good start but it looks like you're
still working on it. You can copy the module into CMake on top
of the current FindMatlab.cmake locally, install sphinx-build, and
then enable SPHINX_HTML in your local CMake build tree to build the
documentation. It will appear in Utilities/Sphinx/html.
- the error messages are more or less message(STATUS... and sometimes
message(FATAL_ERROR, rather than using Xxx_NOT_FOUND_MESSAGE.
So basically if I set this variable to the error message and just
call “return()” from the module scope, it will do the job?
The name_NOT_FOUND_MESSAGE variable is a feature of the helper
module FindPackageHandleStandardArgs. Use that module's macro
at the end of your module to do all the error handling and to set
MATLAB_FOUND automatically.
Most of the STATUS messages should either be dropped or conditioned
on the QUIET option of the invoking find_package command. Some
complex find modules like FindBoost have a special variable the
user can set to get verbose debug output, e.g.
if(MATLAB_FIND_DEBUG)
message(STATUS ...)
endif()
- it looks like I am making too much use of the CACHE.
However, I do not know if the variables like Xxx_INCLUDE_DIRS
should go to the CACHE or to the PARENT_SCOPE.
The singular names that have find_* command calls will be cached
by those commands. Plural names like Xxx_INCLUDE_DIRS should just
be set as normal variables with set() or list(APPEND), etc. They
do not need PARENT_SCOPE unless you are using an internal helper
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 name_NOT_FOUND_MESSAGE variable is a feature of the helper module FindPackageHandleStandardArgs. Use that module's macro at the end of your module to do all the error handling and to set MATLAB_FOUND automatically. Most of the STATUS messages should either be dropped or conditioned on the QUIET option of the invoking find_package command. Some complex find modules like FindBoost have a special variable the user can set to get verbose debug output, e.g. if(MATLAB_FIND_DEBUG) message(STATUS ...) endif() - it looks like I am making too much use of the CACHE. However, I do not know if the variables like Xxx_INCLUDE_DIRS should go to the CACHE or to the PARENT_SCOPE. The singular names that have find_* command calls will be cached by those commands. Plural names like Xxx_INCLUDE_DIRS should just be set as normal variables with set() or list(APPEND), etc. They do not need PARENT_SCOPE unless you are using an internal helper function. CACHE entries should be used only for things that an end user might need to set or change to point at specific things on their system. - some of the variables should be renamed Yes. Also local variables like 64Build should be renamed to have a prefix like _matlab_ and then unset() at the end. - the version matching should be performed in the module, right ? Yes. I haven't read through the module thoroughly yet but please check that it will be compatible with the exiting FindMatlab.cmake that it is replacing. By compatible I mean that the same result variables must be made available to the calling project, even if documented as deprecated. Thanks, -Brad -- Powered by www.kitware.com 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
[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
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 brad.k...@kitware.com 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
