Hi,
Sorry for the delayed answer.
On 11 Apr 2014, at 15:35, Brad King brad.k...@kitware.com wrote:
I avoided using the new syntax of cmake 3.x because I am still using 2.8.12
and I also would like ppl to get this new package and run it on older
versions.
If it is going to be added upstream it needs to have the appropriate
documentation syntax. You can still use comment blocks starting in
'#' on every line as most modules currently do and it will work with
2.8.12.
Sorry for the misunderstanding. It does use SPHINX syntax. I was mentioning the
fact that I cannot use block comments like
#[[.rst:
.. command:: xxx_do_something
#]]
because it is not compatible with cmake 2.8. All doc lines are prefixed with #
instead.
The current solution I am seeing now is to do a test on a cmake
script that does the job of launching the command and flushing
the log file onto the console.
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. What do you think?
- Is it ok if we create log files of leave them onto the disk?
Yes, but they should be inside the CMake build tree so there are
no side effects left when the tree is removed.
Cool. This is what it does.
two modes for querying the registry: x86 and x64 modes.
This is not very clear to me what I should do on that:
The find_library command expands registry values with the view
that matches the target architecture. The find_program command
looks at the matching architecture first and then the other one:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v3.0.0-rc3#l347
This is how most of the modules deal with the difference. I'm
not familiar enough with matlab to say what should be done here.
Well, this is not exactly what I am doing in fact with this module. I query the
registry for all entries below a specific registry key, instead of brute-force
checking all the possible keys.
Now I am using CMAKE_CL_64 for switching the query on the x86 or x64 mode.
Thanks,
-Brad
I added a function add_matlab_mex that is like a add_library for creating MEX
(compiled) extensions. There is an option to this function called
REDUCE_VISIBILITY which deals with symbols collision between the library
shipped with Matlab and the one the MEX file links to (Unix only). Basically,
with this option on, all symbols of the MEX file are hidden, which is more or
less what is happening on Windows.
I attach to this email the updated files.
FindMatlab_TestsRedirect.cmake
Description: Binary data
FindMatlab.cmake
Description: Binary data
So far 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?
BTW, is there any variable that tells the current cmake list, even in function
in packages? The add_matlab_unittest is a function calling
FindMatlab_TestsRedirect.cmake in script mode. When I use
CMAKE_CURRENT_LIST_DIR, it takes the value of the cmake file calling the
function. I would like to reference the call to FindMatlab_TestsRedirect.cmake
relatively to FindMatlab.cmake.
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
