Compile w/o pulling in .mat files?

Hi...

I use either the deploytool or mcc to compile. In my code, I use Load to pull in inputs parameters in .mat files. But those load statements are meant to be executed each time a user runs the scripts. And in fact that works, if I don't compile. If I compile, and the .mat file happens to be in the Matlab path, then the .mat gets pulled into the exe, forever hardcoded into it. But it's supposed to be read in real time, everytime.

I see the deploytool finding it, and adding it, and when I try todelete it from deploy, it puts it right back.

And mcc is worse, it just pulls the .mat in and doesn't tell me.

I can compile if I change the matlab path so the compiler doesn't find the .mat files. Compile in "isolation".

Is there a better way?

Thanks!

Dave

Answer 1

[Image Analyst]

Use the -a option in mcc to build in the .mat file so that it can be called like it's on the search path.

mcc -m myScript.m -a myScript.mat

[David Pesetsky]

That's the opposite of what I need. I want to exclude all .mat files while compiling, so the exe is forced to get it from the current folder.

[Walter Roberson]

reminder that the current folder for exe is typically ctfroot the temporary directory where it expands the ctf archive

[David Pesetsky]

And that would be horrible indeed. But I cd with absolute paths. Really, I should just switch to all input arguments... but it's not my code.

[Image Analyst]

OK, I guess you're like me and like more control and knowledge of what files go where. So that's why I use a third party installation package program called Centurion Setup to package my files for deployment to the target computer. Last I checked, MATLAB's deploytool does not let you specify exactly where you want files to go. So that's why I don't use it.

It's complicated so let me try to explain a little bit. When you compile a program, it makes a standalone executable. So you'd think that if you drop that program in a folder (let's call it C:\David) and ran it, it would be running the executable in that folder - that folder is the "current folder". Surprisingly, it is not. That executable actually unpacks a bunch of stuff (including the REAL executable) to some secret hidden folder somewhere, like C:\Users\you\mysteriousLocation. You can find out that folder if you want. See attached utility. It's where the ctfroot folder is that Walter talked about. The first time you run it, it takes a long time to unpack all the files, like up to 4 minutes, which is confusing to my users, but subsequent runs should be faster. The executable in C:\David actually launches the executable in C:\Users\you\mysteriousLocation.

So the "current folder" is actually there (in C:\David), it's not where you thought it was. So if you put files into C:\David, like .mat files, Excel workbooks, splash images, data files, and any other files that need to be read at run-time, it will not find them because it's not looking in C:\David, it's looking in c:\users\you\mysteriousLocation.

Now, what's really horrible is that you're using cd, something that I believe most expert MATLAB programmers don't do. Why not? See The FAQ

What you want to do, instead of using cd, is to ship/deploy your files to known locations and use fullfile() to construct the full filename. You do NOT want to use cd() and then rely on the file somehow magically being in the executable's CTF folder, or on the search path.

I deploy many, many projects to lab computers that usually have multiple users logging in with their own accounts. I don't want to know in advance all the users and deploy files to their personal folders, so I put all my files needed at runtime in the C:\users\Public\Public Documents\MATLAB\Project Name folder, where Project name is the name of whatever program I'm deploying. That way, any user can see the files. I tell my installer (Centurion Setup) to put the files there, and I use fullfile() to tell my program to look there to get the files.

I know it's confusing and you'll probably have to read my answer several times, but I hope that explains it a bit more. At least that's how I understand it. Walter can correct me if I'm wrong.

[David Pesetsky]

Well, all the inputs to the executables are as absolute paths, but he is doing cd's all over the place. But with absoulute paths. And I am getting the right answers, so far. I even just now screwed up a mat file used as input, and saw the screwed up values flow through to the outputs. The user double clicks the exe in a folder where the .mat input fils are also stored. It seems to load it right away and use it, which is what we need.