deploytool project documentation

8 views (last 30 days)
stijn
stijn on 25 Aug 2011
Is there any information/documentation about the .prj files used by the deploytool? Like an xsd schema? Or source of the deplotool?
Reason I'm asking: we really need the .prj file in our versioning system, so I started by getting rid of all absolute paths and made everything relative to ${PROJECT_ROOT}, which works fine. However when invoking deploytool it gives a warning that there are errors in the file, and I'd like to know which these are.
I'd also want to override the output name etc: for example, we need both x86 and x64 versions, so we want them named foo_x86.dll and foo_x64.dll. So I changed the filenames under the build-deliverables tag but this has no effect. What does work is changing the param.appname tag, but then the header file created contains functions like foo_x86Initialize etc, whereas I'd like these to remain fooInitialize else all code calling this needs to change.
  1 Comment
Michael
Michael on 14 Aug 2013
I, too, wish such a thing were available, for our versioning system. Deploytool is severely lacking for professional development. I've pretty much got things working acceptably, but I always get a strange warning on build:
Warning: Adding path "C:\Users\myusername\Documents\myproject" to Compiler path instance.
which is equivalent to ${PROJECT_ROOT}. Regardless of how I have been able to handle the .prj file, I still get this warning. It doesn't seem to cause any problems, but I it makes me nervous. Any idea why this appears and how to get rid of it?

Sign in to comment.

Answers (1)

Fedor
Fedor on 12 Jan 2012
Did you find an answer to that please? Facing the same issue...
  1 Comment
stijn
stijn on 31 Jan 2012
well I found a way to do it, but it wasn't pretty. The whole mbuild/deploytool system is a piece of cr*p in my opinion. First problem with deploytool.bat is that, although having a '-win32' option, that has no effect whatsoever when deploytool is not invoked from the 32bit install directory. Second problem is that the mbuild options are shared for 32 and 64 bit versions so they have to be specified manually as else the wrong compiler options are used.
Here are some things I did to compile both 32bit and 64bit from a 64bit windows machine with VS2010 installed.
- you have to install both 32bit and 64bit matlab versions
- you'll have to do everything from the command line
- you can never edit your .prj files via the deploytool ui because it screws up all manual changes made to them. (well, that is actually a benefit since now at least you'll be able to tore them in a VCS)
- point to the correct compiler options by adding <param.c.cpp.options.file> to the prj under the 'configuration` section (see below)
- build by manully giving the full path to the deploytool.bat of the 32 bit installation
Note that output dir etc will be the same for the 32bit and 64bit versions. In practice, if you have to do this for multiple projects this becomes totally unmanagable. So I have an msbuild script to make life easier: basically in the prj file I replace everything platform dependent (output dir, matlab root dir, options file location) by macros, then let msbuild copy the prj and do a regex find/replace of the macros with values depending on platform. This allows using the same prj for both platforms. Then there still is the problem that the generated header files are different for x86/x64 versions since the Initialize/Terminate functions get a different name, but that's easy to solve using some preprocessor magic.
I hope you understood anything of the above, if you are really interested I guess I could send you the msbuild files, wothout warranty off course :]

Sign in to comment.

Categories

Find more on File Operations in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!