= Журнал ошибок, проявившихся при разработке проекта Bombono DVD = Pазработка современного ПО построена по модульному принципу. Так, Bombono DVD использует такие проекты, как Boost, Gtk, SCons и другие (всего 10 явных зависимостей, есть и неявные). Однако помимо преимуществ наследуются недостатки и ошибки, включая будущие. С некотого момента я решил завести журнал заметок, в который записываю технические проблемы, проявившиеся в ходе разработки, которые зависели/зависят не от меня (но решать-то все равно пришлось). Смысл в том, чтоб на основе полученных данных более объективно подходить к выбору с кем "дружить", а с кем не "дружить".<> Критерием попадания в список являются все случаи, когда ошибка/поведение/смена API/ABI/... проявилась или добавилась уже после того, когда соответствующий функционал уже прочно задействован в проекте.<> == Список == {{{ SCons: - с версии 2.0.1 стал вылетать при работе нелатинскими названиями файлов - несколько раз менял свое поведение до версии 1.2.0; однако благодаря природе Python выходы находились. - INSTALLSTR, начиная с версии 1.0 может принимать только строковые значения (не функции) - явная ошибка. - расчет md5 путем чтения содержимого файла в строку; при гигабайтовом файле валился авторинг GraphicsMagick: - отсутствие функции OpenCache() в новых версиях сильно попортило нервы; к тому сложности в узнавании какая версия GM используется бесит. Дистрибутивы: - замена toolame -> twolame не дает возможности сделать одну версию для всех дистров. - убрали /proc/scsi/devices из Debian Sid, пришлось изучать исходники ядра. (2 дня потратил). Gtk: - диалог-помощник мой поломали (в Karmic, Sid) - 2 места - синхронизацию ломали (в Hardy) между текущей вкладкой и текущим пунктом в меню Go. - GtkButton - чего-то поменяли в стилях по умолчанию и значки на них перестали показываться - GtkAssistant: - убрали возможность устанавливать страницу до show_all() - поменяли порядок OnApply и OnPrepare (делать что ли нечего!) - GtkDialog - провозился целый день с открытием диалога, если в нем есть метка со ссылкой (бесконечный цикл) - GtkFileChooser (c gtk >= 2.30.0): - выпадение из-за неправильного мониторинга - set_filename() не работает в паре c get_filename() для SELECT_FOLDER GCC: - ужесточили препроцессор так, что код Boost (1.33) перестал компилиться (починил) Winff: - неправильно генерит видео для DVD (опция -target *-dvd должна быть всегда) Totem: - с версии 2.27.1 авторы перестали поддерживать xine backend. FFmpeg: - c версии 0.6 опция -formats разбита на 2, -formats и -codecs - c версии 0.6 поменяли принцип отображения потоков (спасает опция -map) - в будущей 0.7 убрали -padX, а вместо нее — -vf pad=w:h:x:y:black ; само по себе не страшно, но учитывая, что в Packman/openSUSE, например, используют нестабильную версию, то так и хочется взять и ... - в ffmpeg/libav >= 0.7 поменяли имена функций, включая dump_format->av_dump_format, av_open_input_file->avformat_open_input и т.д., смысл ошибочных кодов (ушел AVERROR_NOFMT) - в версиях libavcodec 53.4.x-53.9.x есть ошибка, портящая размеры для h.264, в процессе вызова avcodec_open() (попало в Ubuntu Oneiric); хочется взять и наказать автора патча - прямой доступ, в частности, к ff_codec_bmp_tags закрыт => линковка не производится; узнать имя проблемного кодека стало сложнее - сюрпризы libav 0.8: - качество кодирования сломали в libav 0.8 => сломали в ffmpeg 0.9, но в ffmpeg 0.10 уже исправлено - libav завел свой конвертор, avconv (ffmpeg теперь там только для виду) - поменяли параметр -ab => -b:a - -newaudio убрали, теперь все делается через параметр -map - в ffmpeg заменили точку в выводе "Stream #0.1: Audio" на ":", теперь "Stream #0:1: Audio" (мелочь, а неприятно) - закрыли доступ к ffurl_register_protocol() (политика) MS Windows: - GetStdHandle(STD_OUTPUT_HANDLE) возвращает мусор под XP и 2000, если процесс не присоединен к консоли (но практически всегда этим мусором оказывается "магическое" значение 0x00010001); в документации же (http://msdn.microsoft.com/en-us/library/ms683231) утверждается, что будет возвращен нуль; в 7-ке поведение поправили (стало так, как описано в документации) - в 7-ке системные вызовы kernel32.dll реализованы в kernelbase.dll, и вызов реально идет так: GetStdHandle()->kernel32.dll->api-ms-win-core-processenvironment-l1-1-0.dll(чистая прокся!) ->kernelbase.dll. Смысл усложнять все это - разве что для тех, кто реально хочет знать, что происходит, но не имеет доступа к исходникам. Aх да, ставить "палки в колеса" программистам - любимое занятие Microsoft'а же! - в одной весьма популярной операционке сигналы есть только для вида; пользоваться ими практически невозможно, и вот почему: - послать из одного процесса в другой можно только 2 сигнала, SIGINT(Ctrl-C) и SIGBREAK(Ctrl-Break), все остальные работают только внутри одного процесса - это будет работать, только если оба процесса присоединены к одной и той же (!) консоли - целенаправленная посылка сигнала работает только для SIGBREAK (GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pid)), и только если процесс, которому посылают сигнал, был создан с флагом CREATE_NEW_PROCESS_GROUP; в ином случае сигнал пошлется всем процессам, присоединенных к консоли (включая того, кто посылал) Вывод: какую-либо инфу лучше передавать по-другому, например, с помощью именованных труб (CreateNamedPipe()) - почему стандартная библиотека C++ от MSVC не гут: - std::streamoff 32-битный, потому работать с файлами >= 2GB затруднительно (исправлено только в vs2010) - стандартная библиотека собрана без флага (компилятора) /vd2; последний нужен для полноценной поддержки С++ в компиляторе, и, если он используется (что, вроде как, естественно), то линковать код с MSVC STL нельзя (теряется бинарная совместимость, будут неисправимые ошибки, например, при использовании iostreams) Вывод: STLPort - для паралелльной компиляции есть ключ /MP, но линковщик от MS можно запускать только один (он требует эксклюзивный доступ к PDB); более того, и компилятор в это время не должен работать }}} ----