Как победить условную компиляцию в FDT
Ivan Dembicki
Как победить условную компиляцию в FDT:
Run -> Run Configurations...
Выбираем проект, переходим на закладку Compiler Arguments и добавляем
-define=CONFIG::Debug,false
Но если попытаться использовать вот такую конструкцию:
[code]
CONFIG::Debug {
trace("Config::Debug = true");
}
[/code]
то FDT начинает жутко ругаться на синтаксис - а это раздражает.
Мы понимаем, что парсер лох и его можно обмануть, так что дадим гаду
что он хочет:
Создаем в руте проекта namespace с именем CONFIG.as:
[code]
package {
public namespace CONFIG;
}
[/code]
Cоздадим класс ConfigValues и объявим переменную:
[code]
package {
public class ConfigValues {
CONFIG static const Debug:Boolean = false;
}
}
[/code]
Теперь, мы можем использовать вот так:
[code]
var debug : Boolean = false;
ConfigValues.CONFIG::Debug
{
debug = true;
trace("Config::Debug = true");
}
if (!debug) {
trace("Config::Debug = false");
}
[/code]
- я добавил тест, чтобы убедиться, что всё работает как надо.
Остается только предупреждение, что отсутствует точка с запятой. Это
не так страшно, как грозные ошибки, которые выдавались ранее, но если
сильно раздражает, отключите нафиг эту ошибку в настройках FDT.
Как неожиданный плюс имеем нормальный автокомплит.
Ivan Dembicki
да, если у кого-нибудь будут мысли как улучшить - вэлкам.
И я это не тестировал жестко. Проверьте сами перед использованием.
Ivan Dembicki
еще пара пояснений: значение переменной Debug в классе ConfigValues не
оказывает влияния на условную компиляцию. Имеет значение только
переменная, которую вы передаете в аргументах компилятора.
ConfigValues - не больше, чем фейк.
Flop Serg
давно я это пытслся победить и таки победил
примерно так же неймспэйсом и переменой в нем
но потом постотрел на эти конструкции и забил
условная компиляция и вот такого рода код
как-то не по-мне - что-то ненравится...
уж лучше конфиги и ант - красотень
Yuri Zhloba
Dima Pilipenko
А условная компиляция бывает нужна, и не только для отключения трейсов.
Ivan Dembicki
> а для чего еще?
- применений может быть масса, в том числе версионность продуктов
можно как-то поддерживать.
Nox Noctis
Для сборки отличающихся друг от друга версий одного проекта.
Самый очевидный пример -- дебаговая сборка (мясом наружу, куча
отладочных фенечек прямо на экране конечного пользователя) или релизная
чистенькая.
Кстати, переменные пред-компиляции можно использовать и в обычных
выражениях, не только для того, чтобы компилировать или не компилировать
блок кода. Например:
if (CONFIG::DEBUG) {
...
} else {
...
}
public static const BUILD:String = BUILD::ID;
Ну, и в любых других.
--
Michael Antipin
______________________________________________________________________
fe...@noregret.org | http://skazkastudio.ru | http://noregret.org
Nox Noctis
Она решает проблему с ошибками на инструкциях условной компиляции в
FDT.
Тогда (в версии 3.5.0.1021) прием не работал и я выкинул его из
головы.
Сейчас, в версии 3.5.0.1040, прием работает исправно.
По основному адресу до сих пор лежит версия 3.2.0.1029
http://fdt.powerflasher.com/update/
Чтобы скачать свежее, используйте адрес
http://fdt.powerflasher.com/update_beta/
Проблемы с парсером в FDT можно обрамлять комментариями:
/*FDT_IGNORE*/
код, который FDT парсит криво
/*FDT_IGNORE*/
Тогда парсер будет игнорировать обрамленный блок.
Пример:
/*FDT_IGNORE*/
build::debug {
/*FDT_IGNORE*/
logTarget = new VKLogTarget();
logTarget.includeLevel = true;
logTarget.includeTime = true;
logTarget.setStage(wrapperStage, this);
Log.addTarget(logTarget);
/*FDT_IGNORE*/
}
/*FDT_IGNORE*/
Тем самым я устранил проблему с условной компиляцией (напомню, авторы
FDT прямым текстом говорят, что маловероятно появление поодержки
условной компиляции в ближайшем будущем).
Конечно, если указанный фрагмент кода необходим для нормального
функционирования всего остального кода класса, то ошибок вы не
избежите.
Например, если вы напишете:
/*FDT_IGNORE*/
var callback:Function;
/*FDT_IGNORE*/
callback();
То ошибка, естественно будет: парсер не узнает о том, что есть
переменная callback.
Но, на данный момент, такой выкрутас нужен только для условной
компиляции (и редких проблем с сильно замороченным E4X). Так что
пользоваться вполне можно.
dmitry zhelnin
Проблемы с парсером в FDT можно обрамлять комментариями:
/*FDT_IGNORE*/
код, который FDT парсит криво
/*FDT_IGNORE*/
dmitry zhelnin