2016-07-20 9 views
1

мы используем среду сценариев для автоматической сборки, запуска и проверки автономного исполняемого файла. Мы работаем с Matlab R2010a x64. Компилятор МСС Matlab вызывается из командной строки Windows, построения автономного приложения:Как я могу убедиться, что Matlab mcc не создает неполные автономные исполняемые файлы?

МСС -m -v -w разрешает -I source_folder -I common_folder -a specific_files_we_need our_program

Программа состоит из около 25 модули (файлы .m) и использует около 5 наборов инструментов. Это работает нормально, пока доступна правильная лицензия. mcc проверяет наличие лицензии на компилятор, разрешает зависимости, упаковывает все в исполняемый файл.

Однако, если лицензия не включает необходимые панели инструментов, mcc не выдаёт никаких предупреждений или ошибок. Он создает исполняемый файл без панелей инструментов. Таким образом, исполняемый файл запускается, кажется, запускается с первого взгляда, но падает, если достигается строка кода, требующая инструментария.

Я ожидаю от компилятора, что он информирует меня о недостающих компонентах. Что я могу сделать, чтобы получить информацию о недостающих компонентах? Как я могу убедиться, что mcc не объединяет неполные исполняемые файлы? Я что-то пропустил в вызове mcc?

Предпочтительно, я хотел бы настроить компиляцию таким образом, чтобы она останавливалась, если что-то не хватает.

\ Zweikeks

ответ

1

Самый простой способ в вашем компиляции сценария вы можете проверка требуется лицензии, т.е.

license('checkout','Compiler') 
license('checkout','control_toolbox') 

Вы просто добавить 5 инструментарии, которые должны быть проверены -> если лицензии функция can not checkout лицензии возвращает false, которую вы можете использовать для отмены компиляции.

+0

Это помогает уже, благодаря matlabgui. Однако я должен указать фиксированный набор наборов инструментов. В случае, если разработчик меняет источники таким образом, что нужен другой набор инструментов, компиляция может снова завершиться без уведомления. – Zweikeks

+0

Это правда. Вы могли бы зациклиться на всех зависимых исходных файлах и посмотреть, с какого инструментария они появляются. – matlabgui

0

Это то, что я наконец придумал:

я могу проверить перед компиляцией, которые необходимы для инструментов и вызвать лицензию() соответственно. Или я могу реализовать встроенную проверку самого исполняемого файла. (Вызывается специальным параметром после компиляции, запускает самопроверку для доступных наборов инструментов.) В любом случае мне нужны имена необходимых наборов инструментов.

Я попробовал несколько способов создания списка наборов инструментов. Короче: запуск программы в Matlab, а затем вход в лицензию ('inuse') не очень надежный. depfun() спускается к большому количеству. mydepfun() и fdep() не спускаются достаточно.

Я думаю, что проблема с mydepfun() и fdep() заключается в том, что они не спускаются в папку \ toolbox \ shared. Так что я взял mydepfun() от Tobias Kienzler (link to the original sources) и модифицировали его:

function [list,callers,tboxes_found] = i_scan(f) 

func = i_function_name(f); 

[list,~,~,~,~,~,callers,~] = depfun(func,'-toponly','-quiet'); 

toolboxroot = fullfile(matlabroot,'toolbox'); 
sharedroot = strcat(toolboxroot, filesep, 'shared'); 

intoolbox = strncmpi(list,toolboxroot,numel(toolboxroot)); 
inshared = strncmpi(list,sharedroot, numel(sharedroot)); 

tboxes_found = list(intoolbox & ~inshared); 
tboxes_found = regexpi(tboxes_found, '[\\/]toolbox[\\/](.+?)[\\/]', 'tokens'); 
tboxes_found = cellfun(@(cfun) cfun{1}, tboxes_found); 

list = list(~intoolbox | inshared); 
callers = callers(~intoolbox | inshared); 
for jj = 1:numel(list) 
    c = callers{jj}; 
    cs = cell(numel(c),1); 
    for kk = 1:numel(c) 
     cs{kk} = list{c(kk)}; 
    end; 
    callers{jj} = cs; 
end; 

Таким образом i_scan (е) возвращается в инструментарии, а также спускается в \ Панели инструментов \ совместно. Основная функция mydepfun() только собирает инструментарии:

function [filelist,callers,toolboxes] = mydepfun(fn,recursive) 
. 
. 
toolboxes = {}; 
[filelist,callers,tboxes_found] = i_scan(foundfile); 
toolboxes = [toolboxes; tboxes_found]; 
. 
. 
[newlist,newcallers,tboxes_found] = i_scan(toscan{1}); 
toolboxes = [toolboxes; tboxes_found]; 
. 
. 
toolboxes = unique(toolboxes); 

Инструментарии перечислены те, наш исходный код использует. Модифицированный mydepfun(), похоже, работает нормально. (Помимо типичных проблем, вызванных элементами, разрешенными только во время выполнения, например eval(), ручками функций, обратными вызовами и т. Д.)

И: зависимые ходоки, которые я видел - например mydepfun() - используют depfun() внутри ,depfun() не является надежным, так как он молча игнорирует весь исходный код не на пути (также в этом случае пустая ошибка в этом случае пустая). Поэтому следует принять во внимание, что путь Matlab установлен правильно. (Также любые дополнительные проблемы проблематичны, так как Matlab может неожиданно выполнять одноименные функции из других мест.)

В конце концов, я считаю, что это хороший способ сделать мой процесс сборки более надежным.

/Zweikeks

0

Я только что получил еще один намек на форуме Mathworks. Компилятор выписывает файл mccExludedFiles.log. Это список отсутствующих наборов инструментов. Например

mccExludedFiles.log: 
C:\Program Files\MATLAB\R2010a\toolbox\shared\optimlib\fmincon.m 
called by ...c:\temp\whatever\source\code.m 
(because the required licenses are not available.) 

(Другие недостающие файлы в исходном коде не получить в списке, хотя.)

/Zweikeks

 Смежные вопросы

  • Нет связанных вопросов^_^