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
