Если вы создаёте opensource приложения и не хотите использовать automake/autoconf скрипты, то это программа для вас. Скачать последнюю версию http://www.freehackers.org/~tnagy/bks...
Собственно, bksys - это набор расширений для scons'а (замена для make/automake/autoconf на питоне, рулит, живёт тут: http://www.scons.org). Состоит из трёх-четырёх питоновских модулей общим объёмом меньше 50 килобайт. Для Гнома, я думаю, совсем несложно сваять нечто подобное, даже проще, т. к. нет ни moc'ов, ни uic'ов. Вот только никто до сих не сподобился этого сделать - видимо, гномовцев и automake вполне устраивает. В любом случае советую заглянуть в мануал: http://www.scons.org/doc/HTML/scons-user/book1.html
итак то у нас кроме автоконфа и иже с ним имеется еще - qmake и scons. теперь еще один велосипед будет. scons тот вообще к примеру питон самый последний потребовал - соответственно и не заработал. фффтопку
bksys-1.4.3.tar.bz2 - 136442 байта, из которых 50% приходится на документацию и примеры, 45% на мини-дистрибутив scons'а (scons-mini.tar.bz2, который при необходимости распаковывается и используется) и лишь 5% составляет полезная нагрузка (kde.py и generic.py из каталога admin и ещё пара-тройка мелких файлов, в сумме и получаются те самые 50 килобайт).
>scons тот вообще к примеру питон самый последний потребовал
В README написано: Running SCons requires Python version 1.5.2. У меня такого древнего питона не оказалось, чтобы проверить, но думаю, что это правда.
>имеется еще - qmake и scons. теперь еще один велосипед будат
qmake - в своём роде замечательная вещь, но заточен он только под qt и расширению не поддаётся (написан на плюсах). Т. е. для КДЕшных или, тем более, гномовских прог уже не годится. А про autotools даже вспоминать не хочется. Те, кто писали под КДЕ, знают, что для того, чтобы научить automake собирать KDEшные проги, нужно около мегабайта костылей (перловые и прочие скрипты из каталога admin). Если вспомогательные скрипты занимают больше, чем сами исходники - это ли не костылизм? Увы, разработчики automake'а не позаботились о его расширяемости, поэтому новые фичи к нему приходится прикручивать через задницу. К примеру, научить automake понимать вещи типа KDE_ICON = blabla или METASOURCES = AUTO штатными средствами невозможно, поэтому после окончания работы automake'а запускается специальный скрипт am_edit, который прочёсывает и редактирует ВСЕ Makefile.in. Времени это, естественно, занимает немало, особенно для больших проектов. Ну и то, что по каждому поводу и без повода запускается configure и пыхтит полчаса, тоже нельзя считать приятной фичей. В общем, после перехода на scons/bksys этот ужас вспоминается как страшный сон. А к новым приятностям (автоматическое сканирование исходников на предмет зависимостей, разруливание зависимостей по хэшам MD5 вместо timestamp'ов, кэширование файлов, полученных при компиляции и т. д.) очень быстро привыкаешь. Но если кого-то устраивают autotools - пожалуйста, пользуйтесь на здоровье, никто ж не заставляет срочно портировать всё на scons. =)
>Если у программера не хватает понимания для использования autotools
они умеют им пользоваться, но они не хотят им пользоваться
потому что
Если у тебя например есть утилита с 50 килобайтами исходников, как ты думаешь
сколько она займет если ты захочешь использовать autotools?
больше полмега, и это в сжатом ввиде!!! А их(autotools) забавные изменения версии вместе с потерей совместимости. И т.д. и т.п.
Верно подмечено,.. и уж конечно, обычное Make файло у человека вызывает обморочное состояние... но тем, не менее, хоть и древний, но, один из самых эффективных способов,.. ручками, знаете ли, безо всякой там автоконфигурации..
>и что если написан на плюсах то расширению не поддается?
Имелось в виду, что qmake представляет из себя бинарник, в который дополнительную функциональность никак не засунешь без правки сорцов и перекомпиляции, что явно неприемлемо.
>jam и boost-jam
С этого места подробнее, пожалуйста. Было бы интересно услышать мнение тех, кто их серьёзно юзал и сравнить jam и scons.
> qmake - в своём роде замечательная вещь, но заточен он только под qt и расширению не поддаётся (написан на плюсах). Т. е. для КДЕшных или, тем более, гномовских прог уже не годится.
Почему же ? Аж бегом :) С гномом не возился, а KDE запросто. Впрочем, и без-Qt-шные и даже без X-овые тоже запросто.
> какие могут быть сомнения что autools увеличивает размер проекта в десятки раз?
При том, что распакованные сорцы весят примерно 20 метров, я не вижу тут увеличения размера в десятки раз.
PS Попробуй в том же glib сделать `du -h -c docs glib gmodule gobject gthread' и посмотреть, сколько это всё занимает (Makefile.(am|in)) не учитываем ввиду их малого размера.
Чего вы взбеленились? configure поставляется для того, чтобы если у чека, который собирает проект нет ни automake, ни auotoconf, которые нужны, чтобы по configure.{in|ac} все собралось.
> Если вы создаёте opensource приложения и не хотите использовать automake/autoconf скрипты, то это программа для вас.
Если вам не нравятся велосипеды с круглыми колесами, ты мы разработали с зубчатыми. (Примечание мелкими буквами - для сборки требуется последняя версия кувалды.)
люблю теоретиков. ну хоть ты убейся но тот самый сконс-мини что шел с одним софтом не удовольствовался моим дистрибутивным питоном 2.2. за что и был выкинут на помойку вместе с софтинкой. с автотулзами небыло никогда проблем.
а теперь некто предлагает все работающее заменить на глючево которое хз сколько будут дотягивать и отлаживать.
> вот главный лейб-мотив всех этих нововведений. "нам лень". ага. щаз в угоду им все поламаем. разогнались.
это главный лейб-мотив прогресса целиком. Если бы обезьяне не было бы лень за каждым бананом лезть на дерево - она бы никогда не придумала бы взять в руки палку :)
к теме обсуждения никаким боком. давайте консоль забросим и на винду перейдем, она ведь для домохозяек которым лень регекспы учить. значит типа продвинутее и прогрессивнее
>люблю теоретиков. ну хоть ты убейся но тот самый сконс-мини что шел >с одним софтом не удовольствовался моим дистрибутивным питоном 2.2.
И всё же, scons (и scons-mini) работает под 1.5.2. Что касается bksys, я сам лично его тестил под питоном-2.2 и не обнаружил ни малейших проблем. Единственное, что может смутить юзера - это функция для создания тарболов (содержится в SConstruct). Эта функция использует модуль shutils, и поэтому в самой первой строчке содержит EnsurePythonVersion(2, 3). Функция приведена сугубо в качестве примера, частью bksys, строго говоря, не является, и пользоваться ей вовсе не обязательно. Т. е. если не копипастить её бездумно в свой проект, всё будет прекрасно работать и под 1.5.2.
PS В настоящий момент я как занят тем, что пишу замену для этой функции, которая будет создавать тарболы полностью автоматически (и не будет требовать питон-2.3). В следующих версиях bksys она, думаю, появится.
отлично. это еще раз показывает насколько оно все еще сыро. как и примелькавшийся альтернативный загрузчик сервисов. потому и сравнивать его с autotools на данной стадии просто бессмысленно. надеюсь авторы scons-bksys-олюбы будут вкладывать в релизы альтернативно оба варианта иначе такой подход оттолкнет народ