How to build mex file directly in Visual Studio? - matlab

I have a Visual Studio 2010 solution that contains a library of functions, and I would like to be able to use MATLAB as one of several possible front-ends to this library. Therefore, I would like Visual Studio to automatically generate a mex file when I build the solution, without having to export all my build options and paths to mexopts.bat and open MATLAB to build the file from there. I have seen several suggestions to achieve something similar, for example in these posts:
Matlab 7.1+ and Visual Studio 2005
Compiling a MEX file with Visual Studio
How to use CMake and Visual Studio 2010 (64 bit) to build a MATLAB R2011a (64 bit) mex file?
However, they either seem a bit outdated (making references to files that are no longer to be found) or make use of external tools (eg. CMake). Does anyone know how to set up a new project (within the existing solution) in Visual Studio (2010 and newer) that will build a mex file for contemporary MATLAB releases?

After some experimenting with guidance from this page mentioned in the question, it seems like starting with an empty C++ project the following settings in the project's Property Pages are necessary and sufficient to build a working .mexw64 from Visual Studio 2010:
Configuration properties -> General:
Set Target Extension to .mexw64
Set Configuration Type to Dynamic Library (.dll)
Configureation poperties -> VC++ Directories:
Add $(MATLAB_ROOT)\extern\include; to Include Directories
Configuration properties -> Linker -> General:
Add $(MATLAB_ROOT)\extern\lib\win64\microsoft; to Additional Library Directories
Configuration properties -> Linker -> Input:
Add libmx.lib;libmex.lib;libmat.lib; to Additional Dependencies
Configuration properties -> Linker -> Command Line:
Add /export:mexFunction to Additional Options
$(MATLAB_ROOT) is the path to Matlab's root folder, eg. C:\Program Files\MATLAB\R2013a.
So far this has only been tried from a solution created from scratch and built for Matlab 2013a 64-bit. I assume that to build for 32-bit one only needs to change both occurrences of 64 to 32. I will update the post when I have confirmed that this works for an existing solution.
EDIT: As expected this works for projects added to existing solutions. Remember to set the new project to be dependent on the project that creates the library.
Edit 2: Following this question I can confirm that the above steps work in Visual Studio 2012, 2013, and 2017 too.

Quickly Setting up Visual Studio Projects for MEX files with a Property Sheet
All of the settings can be applied via property sheets, a mechanism for rapidly applying Visual Studio project configurations.
Steps:
Download the property sheet (MATLAB.props) from this GitHib repo.
It's short and sweet. I'd actual urge you to make your own to learn what's involved in the process. See the Property Sheet Details section below for a description.
Set the MATLAB root environment variables: MATLAB_ROOT for your 64-bit MATLAB installation, and MATLAB32_ROOT for any 32-bit MATLAB installations (e.g. C:\Program Files\MATLAB\R2014b\). This folder has the subdirectories bin, extern, sys, etc. Restart VS if it's opened.
Create an empty DLL project in Visual Studio, optionally creating a x64 solution platform. Do this by choosing "Win32 Project" and selecting DLL as follows:
In "Property Manager" (select from the View menu), for each project's build configuration, right click and choose "Add Existing Property Sheet...", and select the appropriate property sheet (32 or 64 bit). (See screenshot below)
That's it!
Just remember that when going between MATLAB to use your MEX file and Visual Studio to build a new version, it will be necessary to run a clear mex or clear specificMEXFileName to be able to overwrite it.
I build almost all my MEX files this way.
UPDATE (05/22/15): The file MATLAB.props now supports the Parallel Computing Toolbox for using mxGPUArray objects. If the toolbox path and library (gpu.lib) exist on your machine, they can be used. Just include the CUDA SDK "Build Customization" (that should be installed if you've installed the CUDA SDK and installed the Visual Studio integrations) to include cuda_runtime.h, etc. Finally, link with cudart_static.lib (but keep Inherit... checked or you will get other linker errors).
Property Sheet Details
There are only a few important settings in the property sheet:
Adding $(MATLAB_ROOT)\extern\include to the AdditionalIncludeDirectories paths (with inherited paths from parent configurations) -- the location of mex.h.
Adding $(MATLAB_ROOT)\extern\lib\win64\microsoft to the AdditionalLibraryDirectories paths -- the location of libmex.lib, etc.
Listing the libraries: libut.lib;libmx.lib;libmex.lib;libmat.lib.
Exporting mexFunction (it's a shared library): /EXPORT:mexFunction.
Setting the output file extention (e.g. .mexw64 for x64).
Not necessary, but it also specifies an output manifest that is NOT embedded in the library, sets MATLAB_MEX_FILE, and turns on generation of data required for profiling.
For completeness, note that there is a more formal "build configuration" system for project configuration, which includes a property sheet, but a loose property sheet is sufficient for setting up a simple MEX project.
A Note About -largeArrayDims
The -largeArrayDims option is a switch to the mex command in MATLAB that simply indicates not to define MX_COMPAT_32. So, in Visual Studio, you don't have to do anything since this is not defined by default. If you want the opposite behavior (-compatibleArrayDims), then define MX_COMPAT_32 in the Preprocessor section.
What's libut.lib for?
I include libut.lib, which provides a few nice functions for detecting a break (CTRL-C) from within a MEX file. The relevant declarations (although this is getting off topic):
// prototype the break handling functions in libut (C library)
extern "C" bool utIsInterruptPending();
extern "C" void utSetInterruptPending(bool);

For building/linking/compiling, automate visual studio with an extension or macro to
start a thin Matlab client (using -nojvm -noawt -nodesktop -nosplash commandline options, this starts in less than a second on my machine)
generate the binary by calling mex (including the other dependencies etc).
if debugging is activated, attached the visual studio debugger to your newly started thin matlab client(any break points you click in VS will be active).
I have automated this for visual studio 2010. This way, you work with your mex-wrapper entirely from the visual studio IDE, have 4 extra pushbuttons for debugging etc. Compile errors are echoed from a matlab terminal window instead of within Visual Studio. Find the Macros uploaded here:
http://www.mathworks.se/matlabcentral/fileexchange/39549-visual-studio-toolbar-for-mex-interface-with-video-tutorial

Related

how to import a Cmake Project which used .sh scripts for build to Vscode?

I have a legacy code base which has CMake configuration and .sh files which calls build commands with respect to build type ( release, relwithdebinfo etc.) as well as does a lot of things.
I have to work over codebase. So far I used STM32CubeIDe. I imported the project as existing Makefile project and then I changed C/C++ Build directory to where makefile outputs converted.
So whenever I did a change on the code, I hit the build command over UI and it calls make command at where I modifed the path above.
This is working but In case of a need of debug then I had to use .elf outputs and OZONE J link Debug program.
I have to do build+debug in same environment but eclipse is slow and making me struggle.
How can I make VSCode host to my legacy code in order to build and debug and also navigate in code i.e go to the definition of code in VSCode, not only building.
Please navigate me if anything needs to share from existing code base, if there is still unclear.

How to produce both x86 and x64 code using MIDL?

How can I generate the code for both x86 and x64 using MIDL?
I've created an IDL file in Visual Studio 2010, and when I compile the product as in x86 mode and afterwards in x64 I've got to "touch" the IDL file so it will regenerate the code relevant for x64. Can I somehow tell MIDL to generate both codes into the same file?
An IDL file defines an interface, that interface could use 64-bit platform features or 32-bit platform features. An IDL can be used to generate a stub; if an interface doesn't have 32-bit-platform-specific definitions or 64-bit-platform-specific definitions, supposedly on stub can be generated (i.e. one IDL file). But, that depends on the interfaces that you're exposing. Short answer: if you define you interfaces to be 32-bit and 64-bit compatible you shouldn't need two different IDL files--otherwise you need two different IDL files.
Without knowing what "touch" (which generally means updating the date/time of a file, w.r.t. software engineering) means, it's hard to say specifically what you need to do.
If you're referring to the files under the Generated Files folder, you won't see them change if all you change is the target platform (well, unless you've placed #ifdef blocks in the IDL that use platform-specific defines). Remember, the output of MIDL is source code, not binaries. The names of the datatypes used in the generated code won't change, so the output from MIDL will be the same even though the machine architecture the compiler is targeting is different.
You can verify this by making copies of the XXX_i.h and XXX_i.c files and comparing them between platforms. To do this, Build, make copies, Rebuild, then compare the files; the only thing that should be different is the timestamp.
So, to get back to your original question: you're already doing it!
I know this is an old question, but should anyone else hit this here is how I solved it.
In the project containing the IDL file, I added a pre-build event to all platforms and configurations that deleted the MIDL output files like this...
if exist $(ProjectName).h del $(ProjectName).h
if exist $(ProjectName)_i.c del $(ProjectName)_i.c
if exist $(ProjectName)_p.c del $(ProjectName)_p.c
I could have gotten away with just deleting the proxy (_p) file as that's the only platform specific MIDL generated file.
If your proxy stub source files have different names or extensions, use those.

Program "make" not found in PATH

I'm having the Program "make" not found in PATH error in eclipse. I checked the path variable which is:
C:\cygwin\bin;
%JAVA_HOME%\bin;
%ANT_HOME%\bin;
%ANDROID_SDK%\tools;
%ANDROID_SDK%\platform-tools;
%ANDROID_NDK%;
%CommonProgramFiles%\Microsoft Shared\Windows Live;
C:\Program Files\NVIDIA Corporation\PhysX\Common;
%SystemRoot%\system32;
%SystemRoot%;
%SystemRoot%\System32\Wbem;
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;
C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;
C:\Program Files\Git\cmd
The PATH starts with the folder which contains make (I checked and make.exe is in there), but eclipse still goes Program "make" not found in PATH.
I have tried changing the path and restarting several times but nothing seems to change.
You may try altering toolchain in case if for some reason you can't use gcc. Open Properties for your project (by right clicking on your project name in the Project Explorer), then C/C++ Build > Tool Chain Editor. You can change the current builder there from GNU Make Builder to CDT Internal Builder or whatever compatible you have.
Are you trying to run "Hello world" for the first time? Please make sure you choose proper toolchain. For Windows you have to choose MinGW GCC.
To make MinGW GCC compiler as default or change you original project with error "Program “make” not found in PATH" or "launch failed binary not found eclipse c++" when you trying to run program simply go to
Windows >> Preferences >> C\C++ Build >> Tool Chain Editor >> Change Current toolchain to MinGW GCC
In MinGW, I had to install the following things:
Basic Setup -> mingw32-base
Basic Setup -> mingw32-gcc-g++
Basic Setup -> msys-base
And in Eclipse, go to
Windows -> Preferences -> C/C++ -> Build -> Environment
And set the following environment variables (with "Append variables to native environment" option set):
MINGW_HOME C:\MinGW
PATH C:\MinGW\bin;C:\MinGW\msys\1.0\bin
Click "Apply" and then "OK".
This worked for me, as far as I can tell.
If you are using MinGw, rename the mingw32-make.exe to make.exe in the folder " C:\MinGW\bin " or wherever minGw is installed in your system.
Just to clarify the details that Adel's linked eclipse forum covers, here's how I solved this (on OS X):
Note: for me, even though my personal environment (i.e. if in bash, echo $PATH) had /Developer/usr/bin in it, I still had to add it to Eclipse's Environment variables:
Go to Eclipse Preferences -> C/C++ -> Build -> Environment -> Add.. -> "${PATH}:/Developer/usr/bin"
In the case of some other OS, just use the right path where make exists.
If you are using MinGW toolchain for CDT, make.exe is found at C:\MinGW\msys\1.0\bin
(or search the make.exe in MinGW folder.)
Add this path in eclipse
window->preferences->environment
Make sure you have installed 'make' tool through Cygwin's installer.
If you are using GNU MCU Eclipse on Windows, make sure Windows Build Tools are installed, then check the installation path and fill the "Global Build Tools Path" inside Eclipse Window/Preferences... :
Probably there are some files inside C:\cygwin\bin called xxxxxmake.exe, try renaming it to make.exe
I had the same problem.
Initially I had setup Eclipse CDT with Cygwing & was working smoothly. One day there happened a problem due to which I had to reset windows. After that when I opened Eclipse I started facing the issue described above. This is how I solved it.
First I searched that in the error the PATH variable value is same as the PATH variable of windows ( just by manual comparison of both two values ). I found that to be same. Now I realized that it is a PATH problem.
Then started looking for Cygwin whether it is there or not? It was there. I located & found that it exists in
C:\cygwin64\bin>
C:\cygwin64\bin>dir ma*
Volume in drive C is Windows8_OS
Volume Serial Number is 042E-11B5
Directory of C:\cygwin64\bin
16-05-2015 18:34 10,259 mag.exe
13-08-2013 04:57 384 mailmail
11-04-2015 02:56 4,252 make-emacs-shortcut
15-02-2015 23:25 194,579 make.exe
04-05-2015 21:36 40,979 makeconv.exe
29-07-2013 11:57 29,203 makedepend.exe
16-05-2015 18:34 79,891 makeindex.exe
16-05-2015 18:34 34,323 makejvf.exe
07-05-2015 03:04 310 mako-render
18-04-2015 02:07 92,179 man.exe
18-04-2015 02:07 113,683 mandb.exe
13-08-2013 04:57 286 manhole
18-04-2015 02:07 29,203 manpath.exe
24-10-2014 13:31 274,461 mate-terminal.exe
24-10-2014 13:31 1,366 mate-terminal.wrapper
15 File(s) 905,358 bytes
0 Dir(s) 373,012,271,104 bytes free
C:\cygwin64\bin>
Then I simply went ahead & updated the PATH variable to include this path & restarted eclipse.
The code compiles & debugging (GDB ) is working nicely.
Hope this helps.
Go to Project> Properties> C/C++ Build> Environment. You will see three fields, choose PATH. See if the folder containing make.exe is appended to the path or not. Sometimes the change to the System PATH variable (made from My Computer> Properties> Advanced System Settings...) is NOT reflected in Eclipse. This solved the problem for me, hope it helps you too!
Additional hint: If you have multiple projects with different toolchains open, check the build console header for the failing project's path.
I've just spent half an hour trying to fix a build that showed this error because another project with hopelessly outdated toolchain settings was open in the same workbench. Closing the other project re-enabled the build.
I also faced this problem but solved it by installing QT and extract the omnet5.6 folder in C:

How to determine if a build is from the editor or command line?

I am building a C++ solution with Visual Studio 2005.
Sometimes I open the solution in Visual Studio and build it from within the development environment. Other times I build it from the command line using msbuild.exe. I'm wondering if there is a way that I can determine which of these two types of builds I'm using at compile time (for example, a macro or something like like that). I want to change the path of my output files based on this determination. So, if I'm building from within Visual Studio I would put my output files in FolderA but if I'm building from the command line I would put my output files in FolderB. Is this possible?
Perhaps you can pass in a command-line parameter when building from the command-line that would indicate you are building the solution from the command-line. Otherwise, you can assume you are building from within Visual Studio.
I don't have the answer to your general question, but in order to change the output path, have you thought of adding project configurations ? You could copy project configurations and update the output path of the new ones.

Microsoft Robotics Studio and absolute path problems

I have just installed Microsoft Robotics Studio 2008 R2, and I must admit that I'm shocked to discover how paths are handled.
First of the studio wants to install itself into my personal profile (this is on Vista):
C:\Users\MyUserName\Microsoft Robotics Dev Studio 2008 R2
I assume this is because during development I have to write files to the robotics studio folder making C:\Program Files a no go.
Then when I create a new robotics project a lot of absolute paths pointing to the robotics studio is added to the project. If I check my project into source control and another developer checks it out onto his machine the absolute paths will not resolve and the project will not compile.
Also, since all services are collected into a single folder in the robotics studio folder developing multiple independent services on a single computer appears to be at least confusing.
Do you have any good strategies for handling this mess?
I have now figured out a way to change a Microsoft Robotics DSS Service visual studio project into something that you can compile and run in you own source tree independent of the installation path of the robotics studio. Here is a description of what you need to do to modify the project:
Add the robotics studio bin path to you PATH environment variable to be able to execute dssproxy.exe without supplying a full path. I have installed robotics studio into the program files folder to avoid accidentially writing files to the robotics studio folders.
Open the Properties page for the project and select the Build tab. In the Output section change the Output path to Debug\bin. For .NET projects it is customary to compile into folders bin\Debug and bin\Release but the robotics hosting service expects to live in a folder named bin and will store data in the folder above the bin folder.
Go to the Signing tab and select a new key in the Choose a strong name key file box. You can either generate your own key at that point or use the sn.exe utility to generate a new key. Or if you have your own policy for creating keys follow that. The sn.exe utility can be found in the tools folder of robotics studio.
In the Build Events tab edit Post-build event command line:
dssproxy.exe /dll:"$(TargetPath)" /proxyprojectpath:"$(ProjectDir)Proxy" /keyfile:"$(SolutionDir)Key.snk" $(ProxyDelaySign) $(CompactFrameworkProxyGen) /binpath:"." #(ReferencePath->'/referencepath:"%(RootDir)%(Directory) "', ' ')
Pay attention to the argument to /keyfile. Enter an expression that locates the strong name key file created in the previous step.
Copy the files DssHost.exe and DssHost.exe.config (or DssHost32.exe and DssHost32.exe.config for the 32 bit hosting service) from the robotics studio bin folder into the project folder and add these files to the project. Set the Build Action to Content and Copy to Output Directory to Copy if newer. Do the same for the manifest file for your service. Actually, the manifest file doesn't have to be in the same folder as the service, but copying it to the output folder enables you to do XCOPY deployment.
In the Debug tab change the Start external program to the DssHost.exe in the output folder of your project. You will have to build the project once to copy the file to the output folder. Clear the Working directory. Set the Command line arguments to
/p:50000 /t:50001 /m:DSSService1.manifest.xml
Change the manifest file name to the proper name in your project. You can modify the port numbers used either here or in the DssHost.exe.config file. If you are running in a protected Windows environment (UAC) you will have to use the httpreserve command to give yourself access to a particular port. You have to run this command as administrator.
Debug settings are not stored in the project file and each developer will have to create personal settings.
You should also update the Release configuration accordingly.
Since I was only interested in the CCR of MS Robotics, I just add these assemblies as a reference to any project I use it with and just be done with it.
This works without any problems. So if you are also only interested in the CCR and DSS part of the studio then this could be your solution
Reinier
we see this problem a lot. The absolute easiest solution is to specify the install directory when installing robotics studio to be "C:\program files\microsoft robotics studio". That way moving code between machines, checking out of source control, etc becomes a lot less problematic.
The other option is to use dssprojectmigration, which is included with RDS. Just run dssprojectmigration against your project directory, and it will correct all the hardcoded paths.