Сборка расширений сродни компиляции, ECMAScript - C-подобный язык, так почему бы не воспользоваться ?

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

Сейчас занимаюсь небольшим проектом, в котором я решил воспользоваться cpp, соответственно есть небольшая наработка, делюсь.

Препроцессор вызывается из пакетного файла jpp.bat, который вызывается из общего сборочного пакетного файла командой

for /r . %%i in (*.s??) do call jpp %%~dpni %%~xi %PRJPATH%\inc

Обрабатываю пока что только *.sjs. Есть два общих включаемых файла, debug.hjs и stdcomps.hjs, они включаются единым для всех остальных файлов проекта включаемым файлом. С их помощью можно писать, например

var io = SERVICE (IO);
var prefs = COMPONENT (PREFS);
return NS_ERROR (NO_INTERFACE);

вместо

var io = Components. classes ["@mozilla.org/network/io-service"]. getService (Components. interfaces. nsIIOService);
var prefs = Components. classes ["@mozilla.org/preferences;1"]. createInstance (Components. interfaces. nsIPref);
return Components. results. NS_ERROR_NO_INTERFACE;

и удалять все 'dump (...)', 'LOG (...)' из расширения, если в общем включаемом файле проекта не определена константа DEBUG.

Включаемый файл проекта: project.hjs, там в основном макросы для определения интерфейса nsIModule 'по умолчанию'.

на мой взгляд паттерн "рееестр" тут больше бы подошёл... вообще говоря Components.classes... - это уже реестр, но уж больно многословный, поэтому можно сделать реестр-враппер с более коротким синтаксисом.

что-то вроде: var io = Reg.getservice('io');

насчёт дампов - не спорю.

ps: в твоём случае экономия получается какая-то однобокая...

#define PREF_COMPONENT_IID nsIPref

Идея хорошая, знать бы как. Неочевидно, как скриптом преобразовать короткое имя в имя интерфейса, а затем по имени интерфейса вычислить contract id класса (мне, по крайней мере неочевидно; есть только соображение об использовании в конкретном проекте оболочки с конкретным набором сервисов). Если у тебя есть идеи по этому поводу, поделись пожалуйста.

Все эти "X_COMPONENT_IID", "Y_SERVICE_CID" и т.п. нужны для макросов SERVICE, COMPONENT.
А экономия касается только "исходных" текстов, разумеется. После препроцессора всё будет развёрнуто, форматирование не сохранится в полном объёме. Тут вопрос в упрощении навигации по "исходникам" (букв меньше, куски кода которые уже отлажены, можно выносить в отдельные файлы) и использовании общих для нескольких файлов определений/констант, которые можно определять/изменять в одном файле.

ну, как минимум @mozilla.org можно добавлять по дефолту...
вообще, я сейчас юзаю вот такую штуку:

var parser =	_('@mozilla.org/xmlextras/domparser;1','nsIDOMParser');
var alertserv=	_('@mozilla.org/alerts-service;1','nsIAlertsService');

если ещё и @mazilla.org обрезать, то вполне себе нормально получится...

форматирование не сохранится в полном объёме

кстати, да. потом же комуто копаться в полученном коде либо осваивать твой препроцессор...

Всё равно короче:

var parser =	COMPONENT (DOM_PARSER);
var alertserv=	COMPONENT (ALERT_SERVICE)

А COMPONENT может развернуться в 'Components.classes["@mozilla.org...' или в '_("@mozilla.org...'

Это проблемы гипотетического "кого-то".

Если кто-нибудь ещё сочтёт это полезным, будут готовые решения, можно будет говорить о каком-нибудь едином "стандарте" на удобные решения. Затем ветка и создана.

p.s.: дополнил свой stdcomps.hjs альтернативой, позволяющей использовать wrappers, если определена константа USE_COMPONENTS_WRAPPERS: http://pastebin.mozilla-russia.org/69982
---
+ альтернатива, позволяющая делать подстановки через глобальные переменные, Ci/Cc если определена константа USE_GLOBAL_COMPONENTS_VARIABLES: http://pastebin.mozilla-russia.org/78613

Немного вне темы, но посетила такая мысль: есть, допустим, некая стандартная библиотека, большинство разработчиков её использует. Есть некий инструмент для сборки xpi и xul-приложений, в состав которого эта библиотека входит. Есть, предположим, приложение, работающее только на FF какой-нибудь десятой версии. Пользователь скачивает исходники приложения и пересобирает его под свой FF восьмой версии, или под SM четвёртой. Или вообще под TB (вдруг да получится).

А по теме, в JavaScript 2, возможно, будет условная компиляция (на самом же js реализованная).

думаю не стоит это слишком усложнять... а то, для создания расширений придётся знать не только язык программирования "яваскрипт",  но и язык программирования "препроцессор"

ага, сишный препроцессор - неимоверно сложный. Хотя, в первом случае, им одним не отделаешься, да и не о нём была речь.