필터 지우기
필터 지우기

deploytool project documentation

조회 수: 1 (최근 30일)
stijn
stijn 2011년 8월 25일
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
Michael
Michael 2013년 8월 14일
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?

댓글을 달려면 로그인하십시오.

답변 (1개)

Fedor
Fedor 2012년 1월 12일
Did you find an answer to that please? Facing the same issue...
  댓글 수: 1
stijn
stijn 2012년 1월 31일
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 :]

댓글을 달려면 로그인하십시오.

카테고리

Help CenterFile Exchange에서 File Operations에 대해 자세히 알아보기

Community Treasure Hunt

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

Start Hunting!

Translated by