I'm trying to use matlab_get_all_valid_matlab_roots_from_registry() from FindMatlab.cmake and print the results using this script:
cmake_minimum_required(VERSION 2.8)
find_package(Matlab REQUIRED)
matlab_get_all_valid_matlab_roots_from_registry(a b)
message("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")
message(STATUS " !!!!! ${a} ${b} ${Matlab_ROOT_DIR} ####")
message("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")
Is it necessary that I first call find_package() before calling matlab_get_all_valid_matlab_roots_from_registry() ?
The output of the script doesn't print the contents of the variables a and b that are return values of that function. This is the output:
1> Command line: c:\program files (x86)\microsoft visual studio\2017
\community\common7\ide\commonextensions\microsoft\cmake\CMake\bin\cmake.exe -G "Ninja" -DCMAKE_INSTALL_PREFIX:PATH="C:\Users\AppTeam\CMakeBuilds\6f0f93b4-4e73-e838-98c8-2bfd807d82bf\install\x64-Debug (default)" -DCMAKE_CXX_COMPILER="C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX64/x64/cl.exe" -DCMAKE_C_COMPILER="C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX64/x64/cl.exe" -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_MAKE_PROGRAM="c:\program files (x86)\microsoft visual studio\2017\community\common7\ide\commonextensions\microsoft\cmake\Ninja\ninja.exe" "C:\Users\AppTeam\Documents\bil\matlab\codegen\lib\mcadd"
1> Working directory: C:\Users\AppTeam\CMakeBuilds\6f0f93b4-4e73-e838-98c8-2bfd807d82bf\build\x64-Debug (default)
1> -- !!!!! C:/Program Files/MATLAB/R2018b ####
1> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
1> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
1> -- Configuring done
It seems that Matlab_ROOT_DIR variable is OK, but I would like to find all MATLAB installations by using matlab_get_all_valid_matlab_roots_from_registry() but the output variables are not displayed. What am I doing wrong?
The proper syntax is:
matlab_get_all_valid_matlab_roots_from_registry(matlab_versions, matlab_roots)
where matlab_versions is an input argument, and should contain a list of the MATLAB versions you want the roots for. Since you pass an empty list as input, you get zero roots back.
According to the sources, matlab_versions comes either from extract_matlab_versions_from_registry_brute_force or matlab_extract_all_installed_versions_from_registry. The former is an internal macro, and the latter is a function available only on Windows. So on Windows you can do:
find_package(Matlab REQUIRED)
set(matlab_versions)
matlab_extract_all_installed_versions_from_registry(ON matlab_versions)
matlab_get_all_valid_matlab_roots_from_registry(matlab_versions, matlab_roots)
message(STATUS " !!!!! ${matlab_versions} ${matlab_roots} ${Matlab_ROOT_DIR} ####")
Also, yes, you do need to issue find_package(Matlab) to make the functions defined therein available.
Note regarding cmake_minimum_required(VERSION 2.8):
If a user has a version of CMake that old (2.8 was released in 2009!), you might find that the user's MATLAB will not be found. The script has a list of known versions of MATLAB to look for, so you need to always use the newest version of the script to find the newest versions of MATLAB (or explicitly add information about the release you are using). The version of the FindMatlab.cmake script in 2009 explicitly looked for MATLAB 7.0 and 7.0 SP1, which were released in 2004, already 5 years outdated at that time, and didn't have the possibility to look for newer versions of MATLAB. This script also did not define a function matlab_get_all_valid_matlab_roots_from_registry.
So, in general, I recommend that you look for the CMake features you are using, and require a version of CMake that supports those features. I know it is common to see "require 2.8" in CMake scripts, but this is not always the best choice. In the case of MATLAB, it certainly is not the best choice.
Related
I've downloaded the binaries: or-tools_VisualStudio2022-64bit_v9.3.10497
I'm using vs2022 on win10. My shell has cygwin in the path if it's related.
I ran
%comspec% /k "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat"
cl.exe is in the path, and which.exe finds it.
I ran make test_cc, but it complained
the cl command was not found in your PATH
exit 127
make: *** [Makefile:271: test_cc] Error 127
The var CXX_BIN was empty even though which cl returned the correct path. I set it manually to cl.
Then, there was a complaint about echo and a newline, which I commented out. Then, it couldn't find md, so I created manually md objs.
A few of the examples were built, but then it stopped with another error. For now, I just got what I want:
make run SOURCE=examples/cpp/solve.cc
but probably there was an easier way to get it?
I tried to build it from the source using cmake. Doesn't work off-the-shelf as well:
Build abseil-cpp: OFF
...
CMake Error at C:/prj-external-libs/vcpkg/scripts/buildsystems/vcpkg.cmake:824 (_find_package):
By not providing "Findabsl.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "absl", but
CMake did not find one.
Could not find a package configuration file provided by "absl" with any of
the following names:
abslConfig.cmake
absl-config.cmake
Add the installation prefix of "absl" to CMAKE_PREFIX_PATH or set
"absl_DIR" to a directory containing one of the above files. If "absl"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
cmake/deps.cmake:33 (find_package)
CMakeLists.txt:304 (include)
If finds gurobi95.dll, but it can't find the function GRBtunemodeladv.
On failure, solve.exe crashes with (unknown) names in the stack trace. Need to add debug symbols and graceful error handling.
cmake looks more promising, and I was missing dependencies. Should give it a flag -DBUILD_DEPS:BOOL=ON.
OR-Tools depends on few external dependencies so CMake build will try to find them using the idiomatic find_package() => your distro/env(vcpkg ?) must provide them, just regular CMake stuff here.
ref: https://cmake.org/cmake/help/latest/command/find_package.html
note: we provide few findFoo.cmake here https://github.com/google/or-tools/tree/main/cmake
We also provide a meta option to build statically all our dependencies, simply pass -DBUILD_DEPS=ON cmake option at configure time.
You can also build only some of them, please take a look at
https://github.com/google/or-tools/tree/main/cmake#dependencies
Concerning Gurobi and GRBtunemodeladv symbol, this one has been removed by last version of Gurobi so we fix it in v9.4/main/stable branch...
see: https://github.com/google/or-tools/commit/d6e0feb8ae96368523deb99fe4318d32e80e8145
I'm trying to integrate cmake into a project that contains a Unity3D project. I want to bypass checks for languages, as the CMakeLists.txt file really just houses a custom command that calls Unity3D's build process. I'm aware of the LANGUAGES NONE setting in the project() command, and also a similar setting in the set_target_properties() command. However, neither seem to be working. My complete CMakeLists.txt file is pasted below:
cmake_minimum_required (VERSION 3.8)
project (
"Test-App"
VERSION
1.0
LANGUAGES
NONE
)
# For the custom command to be marked as not actually creating a file,
# you need to set the symbolic property on it
#set_property (
# SOURCE
# UNITY_OUTPUT
# PROPERTY
# SYMBOLIC
#)
add_custom_command (
OUTPUT
UNITY_OUTPUT
COMMAND
/Applications/Unity/Unity.app/Contents/MacOS/Unity -quit -batchmode -buildOSXUniversalPlayer ${CMAKE_SOURCE_DIR}/Builds/Test-Build.app
COMMENT
"Building application..."
)
add_executable (
Test-Build
UNITY_OUTPUT
)
set_target_properties (
Test-Build
PROPERTIES
LINKER_LANGUAGE
NONE
)
However, in my tereminal output cmake is still complaining that an internal variable has not been set. I get the following output:
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_NONE_LINK_EXECUTABLE
-- Generating done
-- Build files have been written to: XXX
Note that the Makefile is still generated and I can still build stuff. I simply want to get rid of this annoying error, to be sure that I fully understand how CMake is operating.
I am trying to compile a CUDA program using MEX within Matlab2014a and can't get it to work.
I installed the newest CUDA toolbox (6.5) and driver (340.62) and the samples work correctly, so I guess it is correctly installed.
I also installed MS Visual Studio 2012 Professional and Matlab 2014a.
I followed the exact description in the Matlab Help in "GPU Computing -> Examples and How To -> Run MEX-Functions Containing CUDA Code".
My CUDA file ends with .cu (so I am trying to compile Matlab's standard example mexGPUExample.cu, but I get the same error with other .cu files), the mex_CUDA_win64.xml is in the same folder, the environment variable MW_NVCC_PATH is set correctly in the user variables and just to be sure I also called "setenv('MW_NVCC_PATH,...)" in Matlab.
If I try to compile a CUDA example with
mex -largeArrayDims mexGPUExample.cu
I get the following error:
cl : Command line warning D9024 : unrecognized source file type 'mexGPUExample.cu', object file assumed
cl : Command line warning D9027 : source file 'mexGPUExample.cu' ignored
cl : Command line warning D9021 : no action performed
D:\PROGRAMS\MATLAB~1\BIN\MEX.PL: Error: Compile of 'mexGPUExample.cu' failed.
Unable to complete successfully.
I also tried to set the compiler correctly using
mex -setup
and chose the MS Visual Studio Compiler.
The code itself works because I tested it on other systems.
I have no idea what I am doing wrong.
Any help is appreciated.
Matlab only supports CUDA 5.5 on R2014a, so your CUDA 6.5 by default cannot compile mex files under Matlab. Matlab R2014a supports VS 2012 now, but you need to verify you have VS 64-bit compiler if your Matlab is 64-bit. You can compile a normal .mex file with .cpp source file, (lots of these files under matlabroot/extern folder) to see whether Matlab works well with your VS.
Note that Matlab has a lag in supporting the latest compilers, both VS/gcc and Cuda. It is always good choice to check the compiler requirement by Matlab, before using the latest compilers.
Also check whether your Cuda kit and graphics drivers are correctly installed and work seamlessly with VS. You can compile and run some .cu files under the VS environment.
If you have finished all above and changed to the correct version of compilers, follow the instructions on matheworks website to compile the mexGPUExample file. If my memory is correct, you need to set environment variables and copy the XML file to the .mex file path. Then it should work.
I am trying to add a simple library to matlab using the "loadlibrary" function. I first try linking the gcc compiler to matlab with mex -setup and get this:
The options files available for mex are:
1: /Applications/MATLAB_R2012a.app/bin/mexopts.sh :
Template Options file for building gcc MEX-files
0: Exit with no changes
So I just chose 1 and continued. I then received this message:
Warning: The MATLAB C and Fortran API has changed to support MATLAB
variables with more than 2^32-1 elements. In the near future
you will be required to update your code to utilize the new
API. You can find more information about this at:
http://www.mathworks.com/help/techdoc/matlab_external/bsflnue-1.html
Building with the -largeArrayDims option enables the new API.
after this i type in:
loadlibrary('Samplelib.dylib','Samplelib.h')
Error using loadlibrary (line 419)
Failed to preprocess the input file.
Output from preprocessor is:/bin/bash: gcc-4.2: command not found
Any ideas why this is happening?
You are using matlab on mac, true? You need to install gcc first, before you will be able to proceed. Try Xcode - you need gcc-4.2 because it is hard-coded in the mentioned mexopts.sh How to install it depends on your MacOS version, but google xcode, you will find plenty of links.
The first "Warning" is just to tell you that the C API is now better than ever because it supports a huge number of elements, but will need to be enabled using a new option in later versions of Matlab. Long story short, you don't care. The next error about gcc-4.2 means that the gcc 4.2 compiler is not on your path. If you do a:
[s1,r1] = system('which gcc')
disp( r1 )
disp( s1 )
[s2,r2] = system('which gcc-4.2')
disp( r2 )
disp( s2 )
Likely, one or both will come back with an error. Make sure the gcc compiler is on your PATH environment variable.
Like againor says, you'll need to have the compiler installed as well. :-)
I have different behaviour of compiler, when building project from IDE and from command-line, which I can not explain.
The detailed issue's description is rather big, but it's really simple.
I have a C++ Builder project, which has a PAS-file included (IncludeUnits.pas). This pas-file has several units and inc-files listed. These files are located in separate folders and these folders are listed in library&include paths in project's options.
Folders layout:
C:\Demo\Bin
C:\Demo\Project
C:\Demo\Project\CBuilder5
C:\Demo\Project\Common
C:\Demo\Source
C:\Demo\Source\Common
Bin is output folder, Project/CBuilder5 holds project (bpr-file), Project/Common holds included pas-file (IncludeUnits.pas), Source and Source/Common hold other files (pas&inc). I think that it's pretty usual layout.
C:\Demo\Project\Common\ IncludeUnits.pas :
unit IncludeUnits;
interface
uses
Test;
implementation
end.
C:\Demo\Source\ Test.pas :
unit Test;
interface
{$I Test.inc}
implementation
end.
C:\Demo\Source\Common\ Test.inc :
// this file is empty
If I compile this project from C++ Builder IDE - it will compile fine. C++ Builder IDE doesn't have any additional paths in IDE settings set.
Now, I want to compile it from command-line. First, I issue
bpr2mak.exe MyProject.bpr
command.
This command creates MyProject.mak file, where I can see all paths ("....\Source" and "....\Source\Common" are the paths in question):
...
INCLUDEPATH = $(BCB)\include;$(BCB)\include\vcl;..\Common;..\..\Source;..\..\Source\Common
LIBPATH = $(BCB)\lib\obj;$(BCB)\lib;..\Common;..\..\Source;..\..\Source\Common
...
Now, I run make command:
make.exe -B -f"MyProject.mak"
It gives me the following output:
C:\PROGRA~1\Borland\CBUILD~2\BIN\dcc32 -N2....\Bin -N0....\Bin -$Y+ -$W -$R -v -JPHNE -M -UC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common -D_DEBUG;_RTLDLL;NO_STRICT -OC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common --BCB ..\Common\IncludeUnits.PAS
Borland Delphi Version 13.0 Copyright (c) 1983,99 Inprise Corporation
C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(6) C:\Demo\Source\Test.pas(1) C:\Demo\Source\Test.pas(5) Fatal: File not found: 'Test.inc'
As you can see - all search path is passed to compiler and the file (Test.inc) is all here - in that Source\Common folder. But still compiler can't find it?
Of course, I run both commands from folder with bpr-file. And changing paths to absolute doesn't help.
Copying Test.inc from Source\Common to Source will help. Changing {$I Test.inc} to {$I Common\Test.inc} will also help.
Why? It seems that I'm missing something. Remember: project have no problems with compiling from IDE, Test.inc is found without copying or changing declaration. Did I miss some switch to make or dcc32?
I found the reason: command line for dcc32 misses -I switch, which specifies paths for include files.
For some reason, bpr2mak doesn't respect this option. Fortunately, it allows you to specify alternate template for conversion bpr -> mak. I edited default template and added "-I" option to it, pass new template to bpr2mak - and it worked.