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] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
On 03/10/2015 12:57 AM, Geoffrey Viola wrote: Should I still set CMAKE_GHS_COMPILER_ID? I don't see any reason to set a variable by that name. * Have EnableLanguage compute the exact path to the compiler tools itself, possibly using GHS_COMP_ROOT. I prefer the latter approach [snip] finding the comp root is a bit complicated. The registry keys change per version and their does not seem to be a pattern. This should be achievable in C++ inside a helper method called from EnableLanguage. There is no reason to have to use the CMake language to code it. I'll let you know how things work out, after I implement the above. Great, 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 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
[cmake-developers] [CMake 0015439]: ninja: no possibility to control type of path delimiter and line break for linker response file
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15439 == Reported By:Thomas Herz Assigned To: == Project:CMake Issue ID: 15439 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-03-10 16:54 EDT Last Modified: 2015-03-10 16:54 EDT == Summary:ninja: no possibility to control type of path delimiter and line break for linker response file Description: I'm working with the Windriver VxWorks GNU tool chain on Windows host. Compiler Version: ccpentium.exe (Wind River VxWorks G++ DWARF-EH 4.1-131) 4.1.2 --host=i686-mingw32 --target=i586-wrs-vxworks I adapted our existing 'unix makefile' project to ninja builder and I'm getting following linker error: @CMakeFiles/myLib.rsp: No such file or directory Finally, I figured out the reason. Actually, there are two of them: 1) The linker response file uses '\' for path delimiters, but this version of GCC can't handle them, even if it is running on Windows host. It only handles '/' or '\\' correctly. I managed to work around this problem by setting 'CMAKE_COMPILER_IS_MINGW' to '1'. But, I guess, this may have some unwanted side effects. Related bug report: 0015278 2) The linker response file uses Windows style line-breaks (CR-LF) to separate individual object paths. This version of GCC can't handle them. It works fine with Unix style (LF) or without any line breaks and whitespace instead. The behaviour of ninja generator was changed with commit a55d5ca48179d3be4d8406028c0992d45ada8882. I think, this patch is too 'global'. According to commit message 'Avoid LNK1170 linker error' this commit should solve Microsoft compiler/linker problems. Furthermore LNK1170 is not listed anymore for VS2010 and above. Anyhow, for both issues, some kind of automagic with the possibility to change the automagic decision with a particular cmake-variable would be the best solution for such kind of problems. == Issue History Date ModifiedUsername FieldChange == 2015-03-10 16:54 Thomas HerzNew Issue == -- 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 +#
