Re: [cmake-developers] [patch] Support for swig 3.0

2014-07-07 Thread Julien Schueller
What's the point on renaming it ? installing multiple versions ? what's the 
point ?
 I'd say SWIG is rather a very stable utility.
You can safely symlink to /usr/bin/swig.


- Mail original -
 De: Sylvain Joubert joubert...@gmail.com
 À: cmake-developers@cmake.org
 Envoyé: Dimanche 6 Juillet 2014 22:43:45
 Objet: Re: [cmake-developers] [patch] Support for swig 3.0
 
 Le 06/07/2014 21:34, Julien Schueller a écrit :
  This is curious, SWIG does not provide an executable named swig3.0.
  Where did you get swig from ?
 
 
 I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0'
 package. This package provides the '/usr/bin/swig3.0' executable.
 --
 
 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

-- 
Julien Schueller
Phimeca Engineering
www.phimeca.com
-- 

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] [patch] Support for swig 3.0

2014-07-07 Thread Brad King
On 07/07/2014 06:17 AM, Julien Schueller wrote:
 What's the point on renaming it ? installing multiple versions ? what's the 
 point ?
 
 - Mail original -
 I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0'
 package. This package provides the '/usr/bin/swig3.0' executable.

This is a very common convention in distro packaging and is supported
by many of our find modules.  FindSWIG already looks for swig2.0
so it makes sense to also look for swig3.0.  I've applied the patch:

 FindSWIG: Add support for swig 3.0 application
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7400695e

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

2014-07-07 Thread Brad King
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