Для GNOME-приложений представлена новая экспериментальная система сборки BuilDj

11.03.2010 10:46

В рамках проекта BuilDj создана новая экспериментальная система организации процесса сборки GNOME-приложений, призванная в будущем уйти от использования пакета AutoTools (automake, autoconf). Система изначально оптимизирована для сборки графических приложений, написанных с использованием языков C, C++, Python, Vala и дающая возможность прозрачного использования близких к GNOME технологий, таких как intltool, pkg-config, mkenums, gtk-doc, .desktop, .pc, XDG, интроспекция gobject.

Для описания правил сборки в BuilDj используется формат JSON, который является более простым для восприятия, чем XML, предоставляя при этом аналогичные возможности. Для непосредственной сборки проекта, правила BuilDj транслируются в набор сборочных файлов, поддерживаемых выбранным фронт-эндом, в роли которого могут выступать такие системы, как AutoTools, CMake, SCons и Waf.

Основные цели развития проекта:

Простота использования: интуитивность и непротиворечивость создаваемых правил;
Задействование лучших идей из других систем автоматизации сборки, например, недопустимость использования в формате жестко определенных путей к ресурсам, поддержка автогенерации .pc-файлов и прозрачная поддержка средств интернационализации (i18n);
Определение в едином файле всех правил сборки, конфигурации и проверки зависимостей;
Изначальная поддержка кросс-компиляции и гибкой настройки параметров проекта;
Отделение описания правил сборки от функциональности: сборочный формат является абстрактным, легко интегрируется со средами разработки программ. Непосредственная сборка осуществляется фронт-эндом (Waf, Autotools, CMake).

Желание уйти от использования пакета Autotools связаны с проблемами при портировании программ на другие платформы (зависимость от bash и POSIX); постоянной необходимостью обходить подводные камни; не полным документированием всех функций; необходимостью изучать тонкости использования M4/Autoconf, Automake, Make и Bash; плохой расширяемостью; трудностью с восприятием и разбором правил, составленных другими людьми; проблемами интеграции с IDE (правила autotools нельзя просто сконвертировать в разные форматы определения структуры проекта).

исправить +1 +/–

Главная ссылка к новости (http://aruiz.synaptia.net/sili...)

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/25753-gnome

Ключевые слова: gnome, build, compile

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (9)

1.1, Аноним (-), 12:35, 11/03/2010 [ответить]	–1 +/–
Если кто читал документацию, кажется к autoconf, там есть одна маленькая и интересная заметка, что данное ПО разрабатывается для пользователя. Не для ментейнера или разработчика, а именно для конечного пользователя. На протяжении десятилетий мы все дружно нажимаем configure, make, make install и совершенно не думаем головой. Теперь же налетели со всех концов разные умельцы и начинают строчить массу всяческих утилит, поговаривая что мы ошибаемся. Я понимаю, для НИХ это круто, им не надо париться с кучей мануалов на automake, autoconf, autoheader, aclocal, libtool, autoscan, autoreconf, m4. Ну так они ведь умные ребята, могут заботать. Зачем перекладывать проблемы на юзера? Или он теперь стал не достаточно умным, чтобы собирать что-либо из исходников?

2.2, braintorch (?), 13:00, 11/03/2010 [^] [^^] [^^^] [ответить]	+1 +/–
Глупость говорите. Система сборки должна в первую очередь быть удобной для разработчика. Чем удобнее и проще разработчику писать программы под систему, тем больше разработчиков будут писать под неё программы.

3.4, User294 (ok), 13:47, 11/03/2010 [^] [^^] [^^^] [ответить]	+/–
Как бы далеко не факт. История знает много примеров когда разработчики прогибались под не слишком удобные окружения. Например потому что они популярные. И наоборот, даже суперудобность окружения еще ничего не гарантирует само по себе.

2.8, Mike Lee (?), 14:28, 12/03/2010 [^] [^^] [^^^] [ответить]	+/–
> Или он теперь стал не достаточно умным, чтобы собирать что-либо из исходников? вы считаете что чтобы написать ./configure && make && make install нужно больше ума чем для того чтоб поставить из бинарного пакета? и почему для пользователя сложнее написать например cmake . && make && make install? или ваш достаточно умный пользователь не достаточно умен чтобы прочитать readme?

1.3, oops_ (?), 13:21, 11/03/2010 [ответить]	+/–
Велосипед какой-то.

1.5, User294 (ok), 14:30, 11/03/2010 [ответить]	+1 +/–
Такое ощущение что у гномеров закончились все существенные проблемы и они (на пару с КДЕшниками) дружно страдают фигней. Скоро они там социальный десктоп начнут делать? А то некузяво кедовцам проигрывать в страдании фигней :D

2.6, koblin (ok), 15:30, 11/03/2010 [^] [^^] [^^^] [ответить]	+/–
в ubuntu 10.4 уже будут какие-то социальные плюшки, я их правда не осилил :(

1.7, аноним (?), 17:40, 11/03/2010 [ответить]	+/–
Если будет транслировать в CMake то замечательно. Но в таком виде она выглядит как лишняя прослойка.

1.9, Торн (?), 12:29, 15/03/2010 [ответить]	+/–
Несмотря на кажущуюся велосипедность, я считаю этот проект более перспективным, чем все эти маке-гмаке-скунсы-аутотулсы. Прежде всего, он даёт контроль над тем, что и как ты собираешь. Маке в этом плане более фриволен: найдёт сишный исходник - и давай компилять! (правила-то пишут общие, для *.c) BuilDj чётко определяет действия для каждой цели. Второе - это простота формата. JSON понятен человеку, легко [де]сериализуется и поддерживается многими языками, отсюда вытекает прекрасная переносимость на другие (читай неПосыкс) платформы. Да и вообще, дыма без огня не бывает: если кто-то начал что-то делать, значит существующее "что-то" явно не отвечает современным требованиям.

Добавить комментарий

Текст: