[cmake-developers] Introduction and volunteering for the Matlab package

Raffi Enficiaud raffi.enficiaud at free.fr
Wed Feb 18 04:23:19 EST 2015


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.enficiaud at 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.king at 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



More information about the cmake-developers mailing list