Это возможно, но это крайне грязно: по моему мнению, вся система mbuild / deploytool является частью кр * р.Первая проблема с deploytool.bat заключается в том, что, хотя опция '-win32' имеет значение, это никак не сказывается, когда deploytool не вызывается из 32-битного установочного каталога.Вторая проблема заключается в том, что параметры mbuild являются общими для 32- и 64-разрядных версий, поэтому их необходимо указывать вручную, так как в противном случае используются неправильные параметры компилятора.
Вот некоторые вещи, которые я сделал для компиляции 32- и 64-разрядных из64-битная машина Windows с установленным VS2010.
- вам нужно установить как 32-битную, так и 64-битную версии matlab
- вам придется делать все из командной строки
- вы никогда не сможете редактировать ваши файлы .prjчерез интерфейс deploytool, потому что он испортит все ручные изменения, сделанные в них.(ну, это на самом деле преимущество, так как теперь, по крайней мере, вы сможете хранить их в VCS)
- указывают на правильные параметры компилятора, добавив
<param.c.cpp.options.file> к prj в разделе 'configuration`(см. ниже) - сборка путем указания вручную полного пути к deploytool.bat 32-битной установки
config файла опций в prj:
<deployment-project>
<configuration ....>
....
<param.c.cpp.options.file>${MATLAB_ROOT}\bin\win32\mbuildopts\msvc100compp.bat</param.c.cpp.options.file>
....
Обратите внимание, что выходной каталог и т.д. будут одинаковыми для 32-битной и 64-битной версий.На практике, если вам нужно сделать это для нескольких проектов, это становится совершенно неуправляемым.Итак, у меня есть сценарий msbuild, чтобы сделать жизнь проще: в основном в файле prj я заменяю все зависящее от платформы (выходной каталог, каталог корневого каталога matlab, расположение файла опций) на макросы, затем позволяю msbuild скопировать prj и выполнить поиск / замену регулярных выражениймакросы со значениями в зависимости от платформы.Это позволяет использовать один и тот же prj для обеих платформ.
Update
После нескольких серьезных изменений в наших проектах мы обнаружили, что в конечном итоге возникают проблемы с файлами matlab prjне стоило тогоВместо этого мы значительно упростили все, вызвав mcc напрямую и добавив в него все файлы, принадлежащие проекту.Вот соответствующий код msbuild;для наглядности пропущена некоторая проверка ошибок:
<Target Name="BuildMatlabProject">
<PropertyGroup Condition="$(MlPlatform)=='x86'">
<MlMatlabBinDir>$(MlMatlabx86Dir)\bin\win32</MlMatlabBinDir>
</PropertyGroup>
<PropertyGroup Condition="$(MlPlatform)=='x64'">
<MlMatlabBinDir>$(MlMatlabx64Dir)\bin\win64</MlMatlabBinDir>
</PropertyGroup>
<ItemGroup>
<MlMFiles Include="$(MlMatlabProjDir)\*.m"/>
<MlMResources Include="$([System.IO.Directory]::GetDirectories("$(MlMatlabSrcDir)"))"/>
</ItemGroup>
<PropertyGroup>
<MlMresourcseString Condition="@(MlMResources)!=''"> -a @(MlMResources, ' -a ')</MlMresourcseString>
</PropertyGroup>
<RemoveDir Directories="$(MlOutDir)" ContinueOnError="true"/>
<MakeDir Directories="$(MlOutDir)"/>
<Exec Command="$(MlMatlabBinDir)\mcc -W cpplib:$(MlOutputName)_$(MlPlatform)
-T link:lib -d $(MlOutDir) -f $(MlMatlabBinDir)\mbuildopts\msvc100compp.bat
-w enable:specified_file_mismatch -w enable:repeated_file -w enable:switch_ignored
-w enable:missing_lib_sentinel -w enable:demo_license -v
@(MlMFiles, ' ') $(MlMresourcseString)"/>
</Target>
Требуются следующие свойства:
- MlPlatform: x86 для сборки 32 бит, x64 для сборки 64 бит
- MlMatlabx86Dir: путь к 32-битному каталогу установки Matlab
- MlMatlabx64Dir: путь к 64-битному каталогу установки Matlab
- MlMatlabProjDir: путь к директории проекта с m-файлами для компиляции
- MlMatlabSrcDir: путь:с дополнительными исходными m-файлами
- MlOutDir: выходной каталог
- MlOutputName: выходное имя