Is this correct?

Tim.

By the way the spam protection asking me the sum of 3 + 9 seems to think 12 is not the right answer!!! I’ve had to refresh to get a new question.

1. Using ADDPATH in a startup.m file is generally not a good way to manage the use of libraries of M-files in compiled applications. Some alternatives:
* MCC’s -a switch (as you noted above)
* Using a bundle file to automate the inclusion of -a switches on the MCC command line. See the Compiler’s documentation: http://www.mathworks.com/access/helpdesk/help/toolbox/compiler/f13-998373.html.
* Use ADDPATH in an interactive MATLAB session and then save the path (via SAVEPATH). This permanently modifies the MATLAB path, and therefore the path used by MCC.

2. Yes, the state of the path at COMPILE TIME is what matters. Any addpath/rmpath calls in the compiled code will have no effect on what gets included in the deployed application (though they may cause runtime errors for the deployed application, as indicated in the main body of this posting).

3. I’m not sure why the use of disp() should affect performance. This bears further investigation.

4. R2007b enhanced MATLAB’s support for UNC paths, thereby masking the underlying problem: Microsoft DOS commands do not uniformly support UNC paths. MATLAB commands that use DOS commands cannot support UNC paths either. In MATLAB, cd to a UNC directory and then execute system(’dir’); this command will fail because DOS doesn’t support DIR when the current directory is a UNC path.

1. My startup.m has an addpath call in it. When I build a project that calls a function that lives only in the directory that I’ve added, will the depfun magic find that function and add it to the mcc command-line? I know I can explicitly add it to the build command with either “-a” or by dropping the file into the “Other files” part of the deploytool, but my question is why the compiler can’t grab the function at compile-time and automatically include it in the executable. (It seems that it can’t.) If I just included the path with a “-I” would it work?

I understand the compiler has to “freeze” the M-code at compile-time, and can’t use the path at run-time to dynamically locate and run new M-code sitting somewhere on disk. My question has to do with the “right” way to link in code from a library that I use across many projects. Do I have to “-a” every M-file in the library? What do I need to do so that I can rely on depfun to pick up the right functions (and maybe only those that it needs) with as little intervention as possible?

2. Similarly: It’s only the state of the path at compile-time that matters, right? So both me and the compiler should/do ignore any addpath and rmpaths in the code that is to be compiled.

3. A different topic: We’ve seen some evidence that use of “disp()” a lot on in a stand-alone compiled application slows it down considerably, compared to running from the MatLab command-line. Turning off all disp statements makes a remarkable improvement. Haven’t tried something like fprintf() instead yet. Does this make sense? If so, why? Or is something else going on? (Windows I/O buffering is mis-tuned, we’re idiots, . . .?)

4. Someone (”Dan K”, above) mentioned “issues with UNC paths” but I didn’t understand what was wrong with actually using UNC paths. We’ve just started doing this across a Windows network and it seems to work. This way we avoid the use of drive letters, which can be user- and logon-state- dependent. So why not use them . . .?

Thanks for helping clarify some very important points already,

-tom

Compiled MATLAB applications are similar to Java programs and .NET assemblies. All three of these kinds of applications require relatively large virtual machines to run them: Java applications need the JVM, .NET assemblies require the CLR and MATLAB applications need the MCR.

That architecture does not lend itself to single file solutions. You could, of course, package the MCR with each of your executables or shared libraries, and each of your users could install it locally. You might also be able to install the MCR locally on your machine and then share the installation directory across your internal network.

There is currently no way to build a single binary that contains all the code required for a MATLAB Compiler-generated application; we don’t support static linking because of the inefficiencies it creates.

You can’t make the DOS command window go away, but you can make it start up minimized:

http://www.mathworks.com/support/solutions/data/1-1W0CIG.html?solution=1-1W0CIG

1. or only way to get rid of this problem is to get our programs compiled into dll and use VB or other programs for front end /gui and call these gui.
does this not seem a drawback/limitation .

kindly throw some light on the issue.

Yes, the exclusion of ARMAX from your application is a result of licensing; because the ARMAX function performs model estimation, it cannot be deployed.

For more details on the deployability of toolbox functions, see the toolbox deployability table.

C:\Archivos de programa\MATLAB\R2007b\toolbox\ident\ident\armax.m
called by C:\MATLAB\GUI\DEst.m
(because of toolbox compilability rules)

in the excluded files log?

armax its supposed to be used in a standalone windows application I’m trying to deploy.

Thanks