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

[Raffi Enficiaud]

> On 19 Feb 2015, at 16:48, Brad King <brad.king at 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 at madeira3:~/Code/CMake$ which matlab
/usr/bin/matlab
renficiaud at madeira3:~/Code/CMake$ ls -al /usr/bin/matlab
lrwxrwxrwx 1 root root 24 May 15  2013 /usr/bin/matlab -> /etc/alternatives/matlab
renficiaud at 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 at 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