Я бы не сказал, что не нужна. Часто вижу публикацию проектов, где из программ требуется формировать всяческие отчёты и конечно всенепременно в excel. На кой оно надо пользователям, если в общем-то вся логика и так уже в программе имеется, но вот видимо дань традиции. Сам я линуксоид, пишу на Qt, а потому пролетаю пулей мимо в этих случаях, что совсем не радует.
Других вариантов, вроде, нет, я сам потратил кучу времени в поисках решения. Хотя конечно странно это. Оба формата описываются одной спецификацией, а кроссплатформенной реализации до сих пор не появилось.
@archerz да, он вызывается, я тоже думал, что может не видит gcc, но нет, тут порядок. Я visual studio через панель управления удалил, в "Program Files" тоже вроде чисто, но может что-то всё равно осталось. Просто у меня больше нет вариантов, кроме как попробовать с нуля систему залить, поставить Qt и попытаться заново собрать boost.
@archerz значит я PATH, получается, неверно прописываю? Но ведь именно к "C:\Qt\Qt5.2.0\Tools\mingw48_32\bin". Я в тупике. Я у себя смотрел PATH, там нет никакого намёка на msvc. Почему "build.bat mingw" пытается найти msvc для меня загадка. Может какие-то "хвосты" остались с того времени, когда msvc был установлен в системе... В общем надо попробовать на чистой виртуалке. Спасибо Вам :)
Я пытался выполнить "build.bat mingw" из папки engine, но скрипт завершался с ошибками, которые говорили о безуспешных попытках отыскать msvc. На этом этапе ни b2, ни bjam ещё не созданы, т.к. "build.bat" собственно их и должен подготовить. В системе не установлены ни msvc, ни mingw, только Qt5.2, у которого в комплекте в папке Tools свой mingw4.8. Таким образом, получается, что либо я PATH неверно указываю (но здесь как бы трудно ошибиться), либо у Вас на самом деле вместо Qt'эшного mingw "build.bat" берёт отдельный mingw, который установлен в "C:\MinGW" (путь к компилятору почему-то указан хардкодом в "build.bat"). Либо может быть ещё какая-то причина. Вы пробовали запускать "build.bat" без установленного отдельно mingw?
Собрал сегодня под mingw последний релиз OpenCV 2.4.8 (та же версия Qt, что и у Вас). Отвалилось воспроизведение видеофайлов. Они не открываются cv::Capture'ом. При этом видеозахват с вебки работает. В линукс с этой же версией библиотеки как всегда всё работает из коробки. Похоже, что и у меня теперь проблема с этой dll ffmpeg :))
Дело в том, что bootstrap.bat в корне исходников делает как раз именно это: переходит в папку engine и запускает build.bat с переданным "бутстрапу" аргументом (наименованием компилятора). Тем не менее, я пробовал делать и непосредственный запуск build.bat, однако последний не реагирует ни на передачу "mingw", ни на "gcc" в качестве аргумента "тулсета". Установка пути к Qt'эшному mingw в PATH также ничего не даёт. Иными словами, до b2 или bjam дело попросту даже не доходит, т.к. не определяется корректно компилятор, скрипт всё время пытается использовать msvc. Причём, как пишут в инете, эта проблема имеет место быть именно в версии 1.55.0.
1) Погодите, то есть Вы собираете на 32-битной ОС инструментарием x64? То есть и Qt и OpenCV берёте 64-х битные?
2) Переменные среды (PATH) вроде можно посмотреть почистить по правой кнопке на "Мой компьютер" (сам линуксоид, поэтому точно не помню).
Я сначала тоже собирал свои проекты x86 (с x64 не собирал) посредством msvc, но потом занялся mingw. Всё хорошо, кроме одного - в OpenCV разрабы не ко всем версиям библиотеки делают соответствующие сборки под mingw. Но даже когда и делают, то не всегда те совместимы с версией mingw, идущей в комплекте с Qt. В итоге, приходится выполнять сборку самостоятельно. Но ни разу проблем не возникало, достаточно одной Gui CMake для этой задачи.
Да, делегат - это просто средство подстановки собственных виджетов в ячейки представлений. Плюс, делегаты через соответствующие виртуальные методы могут работать с данными модели.
