Черный баг или большое разочарование

Этот пост будет о самом грустном, а именно о багах компилятора mxmlc, которые мало поддаются логическому осмыслению и локализации - и поэтому отнимают особенно много времени и сил. Постараюсь описать их, в надежде что когда-нибудь это поможет и Вам, начну с более понятных багов.

• -incremental=true

  При использовании инкрементной компиляции, mxmlc создает project_123456.cache файлы, в которых хранит скомпилированный но не “прилинкованный” код - так он уменьшает время повторной компиляции, перекомпилируя только измененные и импортирующие измененные файлы

  Существуют неизвестные проблемы, по которым в результате использования этой возможности в результате может собраться полная чушь. Для дебага это не страшно - всегда можно удалить .cache и пересобрать, но не советовал бы использовать инкрементную компиляцию при сборке публичных версий проекта.

• CSS-файлы со стилями, находящиеся не в корне одной из папок из -source-path.

  Описание в Adobe JIRA. Если .css-файл

  .text { borderSkin: ClassReference("com.adobe.skins.MyRectangularBorder ");

  который Вы пытаетесь скомпилировать в .swf, лежит в папке src/assets/, а не в src/, то при компиляции Flex Builder-ом Вы будете иногда получать ошибки вида

  1120: Access of undefined property MyRectangularBorder" and "1172: Definition com.adobe.skins:MyRectangularBordercould not be found.

  При компиляции же из командной строки Вы будете получать их всегда. Еще иногда вам могут сказать, что у .css-файла указан неправильный package (sic!) - хотя у .css файлов package-а не бывает принципиально.

  Workaround - класть все компилируемые .css в корень папок из -source-path.

  Gaurav Jain из команды Adobe считает, что это не баг. На данный момент issue закрыт, нельзя ни проголосовать, ни оставить комментарий.

• CSS-файл может быть не найден, если он находится в разных source-path с использующим его MXML-кодом.

  Описание в Adobe JIRA. Снова наш друг Gaurav Jain. Как он ни старался убедить всех, что “I don’t think its a bug", пофиксить все-таки пришлось.

• Использование “/” в начале Embed(source="/…") не работает при компиляции из командной строки.

  Описание в Adobe JIRA. Тут уже дело в том, что Flex Builder и mxmlc имеют разные механизмы разрешения путей. Jono, я в Вас верю, добейте этот баг.

• Ошибка в одной из Embed-директив может заставить компилятор показать ошибочными все Embed-директивы.

  Описание этого бага в блоге. В комментах упоминают, что это может быть вызвано даже не ошибкой в одном из Embed-ов, и вот мы подходим к самому плохому.

• Ошибка в компиляции любого файла (ваша или компилятора) крайне редко может быть отображена компилятором как ошибка в никак не отсносящемуся к ошибочному коде.

  Сразу скажу, перед каждой попыткой сборки я делал полное удаление .cache и всего, что было собрано в прошлый раз.

  I believe что такие баги есть и что именно этот, самый черный вид ошибки компилятора, я и испытывал на себе весь сегодняшний день. Было несколько ситуаций, когда я менял ревизию одного файла LeftTreeNav и на 663 ревизии все отлично работало, а на 664 мне выдавалось 3 ошибки в файле ContactsWindow и 20 ошибок неверных Embed-директив. Разница между ревизиями была в добавлении нескольких безобидных строк кода, не имеющих никакого отношения к показанным ошибкам.

  Далее - еще интересней. Путем переформатирования файла ContactsWindow я добился исчезновения этой ошибки при компиляции с указанием

  -define+=CONFIG::deployMode,'\'debug\''

  Однако, при указании

  -define+=CONFIG::deployMode,'\'test\''

  она появлялась снова (все остальные параметры компиляции оставались те же). Не могу передать всех эмоций…

  В итоге, все спасло замена большого switch-блока в ContactsWindow на if-else-if-else-if-… Несколько постов назад я писал про хитрые баги в компиляции сложных условных конструкций, и видимо сейчас проблема была как раз тут. Не получив рабочего результата в классе ContactsWindow, компилятор уходил в пике и не возвращался, попутно сыпя несуществующими ошибками из остальных классов.

Надеюсь, Вы никога не столкнетесь с подобными вещами А если столкнетесь - то обязательно напишите, что это было и как починилось. Удачной сборки!

Bookmark this article at …