Make 3.81

> compiler -u $(зависимость с расширенем .ucf) $(все остальные зависимости)

С помощью make это тоже легко делается. Надо только доки читать. Задаётся неявное правило и можешь даже неизвестную цель задавать - постройт. Читать доки на make на предмет Implicit rules. Makefile - декларативный документ.

>> compiler -u $(зависимость с расширенем .ucf) $(все остальные зависимости)

> С помощью make это тоже легко делается. Надо только доки читать. Задаётся неявное правило и можешь даже неизвестную цель задавать - постройт. Читать доки на make на предмет Implicit rules. Makefile - декларативный документ.

А можно таки пример. А то когда мне это было надо я этих доков учитался по самое не могу. Проблему я обошёл, но всё таки хочется увидеть красивое и правильное решение.

Не знаю, у меня make отлично сам определяет зависимости с помошью gcc.И всякие сконсы не нужны :)

Это у него уже определены Сишные Implicit rules. Но они нужны в основном в простых случаях (на которые раскладываются сложные).

nmake от MS - мрачное поделье.

> А то когда мне это было надо я этих доков учитался по самое не могу. Проблему я обошёл, но всё таки хочется увидеть красивое и правильное решение.

Значит плохо читали. Почитайте упомянутую главу в info make. Если обошли внешним скриптом - значит совсем плохо читали.

Сейчас нет времени перечитывать доки (я на работе) и писать пример. Примеры есть дома - но это только вечером.

>> включаются ли в scons сторонние билдеры (как модули или ещё как) > Естественно. =) >> и насколько просто/удобно их писать > Если есть опыт общения с Питоном, то очень просто/удобно. > Ещё scons умеет: > - автоматически определять зависимости

Да, но у него там для этого свой parser, т.е. в случае

#ifdef __blah_blah_blah # include <qq.h> #endif

он проставит qq.h в зависимости безотносительно того, определено ли __blah_blah_blah или нет. С tricks вроде

#include prefix##os_name

такая же фигня. [тут следует вспомнить, что #defines присутствуют i) в компиляторе (pre-defines) ii) системные headers iii) user's ones].

> - строить глобальное дерево зависимостей (кто пользовался autotools'ами, тот знает :P)

Да. Навязчивая попытка выполнить работу ld до ld несколько раз была моей головной болью. [лучше бы такого чуда как autotools не было...]

> - кэшировать (чтоб лишний раз не пересобирать одно и то же) > - определять, изменился ли файл по его контрольной сумме (md5), а не по дате, как make

Ну, вот это резонно.

> - автоматически добывать исходники из CVS, SVN и др. репозиториев

Это вы make'а не знаете. Это есть в 'стандартных' правилах --- однако я всегда перекрываю их (пустыми), поскольку это несёт гораздо больше проблем, чем удобств.

Вывод: scons рулит не по-детцки там, где нет make (Wins?) [список целевых платформ включает те, где нет make].

>Не знаю, у меня make отлично сам определяет зависимости с помошью gcc.И всякие сконсы не нужны :)

ну да. два вызова gcc, для построения дерева зависимостей. И так каждый раз, при более-менее серьёзных изменениях в проекте, ага. зато "входит и выходит, аххххх" :)

>>compiler -u $(зависимость с расширенем .ucf) $(все остальные зависимости)
если вы не знаете make то это говорит только о вашей безграмотности

серебренной пули не бывает
как и у make у scons есть проблемы
не такие как у make, но не меньшие
- чего только стоит глобальность сборки и монолитность сборочных скриптов

в общем - scons не лучше make, просто другой
- кстати использование md5 - глупость
а тому кто сказал что scons не будет пересобирать если ты
изменишь только комментарий - яйца оторвать - за дезинформацию

> А то когда мне это было надо я этих доков учитался по самое не могу. >Проблему я обошёл, но всё таки хочется увидеть красивое и правильное >решение.

>Значит плохо читали. Почитайте упомянутую главу в info make. Если >обошли внешним скриптом - значит совсем плохо читали.

Бросьте пороть чушь, ей больно. Стандартный мейк, вообще не имеет средств построения дерева зависимостей (и упомянутые implicit rules -- тут очень косвенным боком). Другой вопос -- возможность вызова компилятора (или других внешних средств), умеющих строить таковое древо, это да. Но 1) это всегда, двойной вызов 2) не оперативно 3) получающиеся правила сборки очень трудно сопровождать, на сколь-либо крупных проектах, из-за чего, собственно, почти никогда мэйк как таковой, в *крупных* проектах, и не используют -- предпочитая разные варианы tmake,imake и т.п. с шаблонной генерацией. И всё равно, получается такой тошнотный монстр... 4) кто сказал, что на целевой платформе проект будет собираться gcc, да ещё умеющим строить зависимости?

Короче, было бы в мэйке всё хорошо, никто бы не стал тратить время на разработку альтернатив. Но увы, мэйк неудовлетворителен для проектов среднего и большого размера (кстати, процент неверно отмеченных мэйком для пересборки или наоборот, непересобранных файлов -- довольно заметен, особенно, на быстрых машинах. Так что насчёт "у меня не ошибается" -- не надо. Честнее говорить "я не замечал", поскольку жалобы на неверную сборку -- регулярны от самых разных людей). И более чем неудовлетворителен, для многоплатформенной разработки.

Возможно, можно придумаь инструментарий посерьёзнее и совершеннее сконса, на на сегодня(!), примеры мне, неизвестны. С удовольсвием приму к сведению. А мэйк (чистый, разумеется) -- своё отжил, как динозавр эпохи pdp-11/ДВК/386 :) Вряд ли вообще стоит серьёзно закладываться на столь примитивный и неинтеллектуальный инструментарий.

>Да, но у него там для этого свой parser, т.е. в случае

>#ifdef __blah_blah_blah # include <qq.h> #endif

>он проставит qq.h в зависимости безотносительно того, определено ли >__blah_blah_blah_ или нет. С tricks вроде

Я не уверен, научился ли уже сконсовский парсер раскрывать макросы, но в любом случае, большой беды тут нет. Второй уровень конроля -- по md5 -- сводит возможную лишнюю работу до минимума. Не говоря уж о том, часто ли в проекте меняется qq.h, при неопределённом __blah_blah_blah_ ?

>#include prefix##os_name

в точности, тоже самое. Не говоря уж о том, что лучше такого стиля избегать -- по понятным причинам.

>Вывод: scons рулит не по-детцки там, где нет make (Wins?) [список целевых платформ включает те, где нет make].

глупость какая, извините. Попробуйте поработать со сконсом немного, сами. И делайте выводы. Ещё раз: машина должна работать, а человек -- думать, а не писать скрипты для тупого мэйка. Вот для этого и нужен (как частное усовршенствование) -- сконс... у который, наверное, в своё время тоже, сойдёт со сцены, уступив место более совершенному и удобному инструменту.

>>> Стандартный мейк, вообще не имеет средств построения дерева зависимостей
Стандартный мейк, вообще не должен средств построения дерева зависимостей

Keep It Simple, Stupid !!!

> - чего только стоит глобальность сборки и монолитность сборочных скриптов

??? поясните, не улавливаю.

> - кстати использование md5 - глупость

гм. альтернативы?

> а тому кто сказал что scons не будет пересобирать если ты изменишь только комментарий - яйца оторвать - за дезинформацию

читаейте внимательнее, пересобирать -- конечно, будет, текущий парсер не настолько интеллектуален. Но если результирующие объектники не изменятся, не будет полной пересборки всего проекта.

>> Стандартный мейк, вообще не имеет средств построения дерева зависимостей

> Стандартный мейк, вообще не должен средств построения дерева зависимостей

>Keep It Simple, Stupid !!!

Вот именно, дурачок. env.Program(target="ogo.exe",source=VeryBigList) Проще -- некуда, в отличие от правил мэйка. Ошибиться -- невозможно.

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

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

>> - кстати использование md5 - глупость
> гм. альтернативы?
timestamp - вполне достаточно - просто и эффективно


>>а тому кто сказал что scons не будет пересобирать если ты изменишь только комментарий - яйца оторвать - за дезинформацию
>читаейте внимательнее, пересобирать -- конечно, будет, текущий парсер не настолько интеллектуален. Но если результирующие объектники не изменятся, не будет полной пересборки всего проекта.

1) проблема в том что простое правило пересборки будет выглядить на порядок
проще под make и будет иметь эффективность эквивалентную для спецефического
скунсовского билдера (до погрешности ожидания выполнения команды)
2) скунс решает проблемы которые проблемами то и не являются

scons:
env.Program(target="ogo.exe",source=VeryBigList)

make:
ogo.exe:$VeryBigList

Keep It Simple, Stupid !!!

1) простая задача:
у меня есть проект состоящий из 17 модулей
в которых по 17 подмодулей в которых по 17 подмодулей
при запуске сборки 1 модуля !!!!
посредством скунса я успел пить кофейку с девченками, принять душ ...
и в конце получил сообщение об отсутствии памяти ....

2) у меня есть система состоящая из простого ядра, простого шела и компилятора
что бы осуществлять сборку мне достаточно портировать 1 make
для скунса ..... я сдохну быстрее чем соберу что-нибудь приличное ...

>>??? поясните, не улавливаю. >если скунс собирает то он собирает все .... >а не только то что мне нужно -- и это проблема дизайна скунса

нет, это проблема -- что ему указано собирать (т.е., руки... в конечном итоге)

>timestamp - вполне достаточно - просто и эффективно

просто -- да. но практика показывает, что уже НЕ эффективно, особенно при многопоточной сборке.

>1) проблема в том что простое правило пересборки будет выглядить на >порядок >проще под make и будет иметь эффективность эквивалентную для >спецефического

ключевое слово -- простое, но примеры из букварей -- неинтересны

>make: >ogo.exe:$VeryBigList

угу. фишка в том, что сконсовское правило реально *достаточно* и будет работать всегда, а приведёное тобой -- годится только для иллюстрации идеи.

>>??? поясните, не улавливаю. >если скунс собирает то он собирает все .... >а не только то что мне нужно -- и это проблема дизайна скунса
>нет, это проблема -- что ему указано собирать (т.е., руки... в конечном итоге)

как раз проблема - сначала скунс пытается собрать все а потом уже решает
что что-то собирать не нужно - он монолитен

>>timestamp - вполне достаточно - просто и эффективно
>просто -- да. но практика показывает, что уже НЕ эффективно, особенно при многопоточной сборке.

разруха ... она в головах ....

>>1) проблема в том что простое правило пересборки будет выглядить на >порядок >>проще под make и будет иметь эффективность эквивалентную для >спецефического
>ключевое слово -- простое, но примеры из букварей -- неинтересны

разруха ... она в головах ....

>>make: >ogo.exe:$VeryBigList
>угу. фишка в том, что сконсовское правило реально *достаточно* и будет работать всегда, а приведёное тобой -- годится только для иллюстрации идеи


реально *достаточно* ???
даже если у меня ни одного билдера нет ??
или билдера под эту платформу, под этот компилятор ??
или $VeryBigList - совсем не список файлов ??

я что то пропустил - искуственный интелект уже создали ?

>1) простая задача: >у меня есть проект состоящий из 17 модулей >в которых по 17 подмодулей в которых по 17 подмодулей >при запуске сборки 1 модуля !!!!

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

даже верю, хотя и с трудом. А зачем было весь проект строить монолитно? Впрочем, даже в этом случае, скорее. с трудом. Надеюсь, отдельный модуль, был оформлен в отдельный SConscript?

>2) у меня есть система состоящая из простого ядра, простого шела и >компилятора >что бы осуществлять сборку мне достаточно портировать 1 make >для скунса ..... я сдохну быстрее чем соберу что-нибудь

Ну вот. Путаем ежа с ужом, айяйяй... 1) этапы "раскрутки" (bootstraping) и наполнения полным набором софта -- разные вещи, не надо подменять понятия. Естественно, на нулевом этапе, по *необходимости* используется примитивный инструментарий... вполоть до набора кода компилятора в hex из резидентного моитора, помним, ага. 2) Никто не отменял (и наверное, это разумнее всего на этапе первоначальной "раскрутки" системы) кросскомпиляцию. И тут уж никто не мешает пользовать тот же сконс -- на всю катушку. Что, кстати, сэкономит массу сил и времени :)

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

>даже верю, хотя и с трудом. А зачем было весь проект строить монолитно? Впрочем, даже в этом случае, скорее. с трудом. Надеюсь, отдельный модуль, был оформлен в отдельный SConscript?

вот видишь
я гиперболизировал, а ты поверил, хоть и с трудом :)
значит достаточно реалистичный пример :)))

>А зачем было весь проект строить монолитно?
это не ко мне - 1
2 - скунс склоняет к такому стилю .... по моим наблюдениям


>>2) у меня есть система состоящая из простого ядра,
>Ну вот. Путаем ежа с ужом, айяйяй...

я гиперболизировал - привел пример не масштабируемости сконса

>реально *достаточно* ??? >даже если у меня ни одного билдера нет ?? >или билдера под эту платформу, под этот компилятор ??

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

PS: чем уточнение правила для мэйк'а ( ...ifeq ($(BUILD_SHARED),yes) DEP_LIBS=бла-бла/$(бла-бла-REF)бла-бла$(бла-блаSUF) и ещё много бла-бла else DEP_LIBS=... .....

mylove$(EXESUF): fajlo1.o .libs $(CC) $(LDFLAGS) $(OTHERFLAGS) -o $@ blabla.o $(ANOLIBS) $(EXTRALIBS)

), принципиально отличается от написания билдера, кроме примитивизма, меньшей функциональности и железной повторямости в каждом сценарии?

> как раз проблема - сначала скунс пытается собрать все а потом уже >решает >что что-то собирать не нужно - он монолитен

э, понятно. помнится, во 2-ом, кажется, Гришке Горшкове, был такой персонаж -- мистер Гилдерой Локхарт. Тому тоже всё казалось очень простым (наверное, он тоже, не читал инструкций!)

сконс собирает "не всё подряд", а всё, вынесенное в логическую еденицу. Не потрудились разбить проект, а сделалиЮ как привыкли, монолитный мэйк? Ну, сами себе враг, значит (PS: как известно, правила работы даже с таким простым инструментом, как молоток, отличаются -- в зависимости от того, в руках у вас часовой молоточек или кувалда! чего же вы хотите от инструментария с совершенно разной идеологией)?

>>timestamp - вполне достаточно - просто и эффективно >просто -- да. но практика показывает, что уже НЕ эффективно, особенно при многопоточной сборке. >разруха ... она в головах .... Тщательнее надо, м-р Локхарт! и особенно осторожно с цитатами из Булгакова -- их хоть и опошлили, всегда есть шанс нарваться на настоящего историка :)

>А зачем было весь проект строить монолитно? это не ко мне - 1 >2 - скунс склоняет к такому стилю .... по моим наблюдениям

совершенно неправильное наблюдение. сконс, наоборот, предоставляет все средства для разгребания срача в сборочных каталогах, от элементарного отделения .../build для объектников и отдельных /build/linux /build/windows и т.д., до полной модуляризации всего проекта. Читайте доки, вместо буржуазных газет :)

> я гиперболизировал - привел пример не масштабируемости сконса

а это вообще, неверно. Впрочем, что разуметь под масштабируемостью. Да, разумеется -- на платформе, где нет даже питона -- говорить о запуске малоосмысленно (да и нужно ли? вряд-ли там можно (оправдано) собрать что-то сколь либо сложное), но масштабируемость -- это не только (и не столько!) "запуск на кастрированных платформах", а скорее, возможность широкой вариации функциональностью. А с этим, опять-таки в отличие от классического мэйка -- никаких проблем. Хоть с голого ядра начинайте плясать (дизайн -- полностью модульный).

хм
у меня как-бы работа есть
спорить неохота, да и нет обходимости

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

>Пора убить это поделие... scons форева!!!

Бессмертные не умирают!

> так как проблем он создаст не меньше чем make >а многие преимущества мэйка будут утеряны

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

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

с одной стороны, верно. с другой -- самый яркий консерватизм -- "мэйк" на батч-файлах cp/m. а что, работали-же люди?

>пишут программисты - и дождаться что они сделают .....

В том то и дело - для себя делают, т.ч. надежды есть.

Народ, а что вы скажете о cook? http://www.canb.auug.org.au/~millerp/cook/cook.html

>> так как проблем он создаст не меньше чем make >а многие преимущества мэйка будут утеряны
> очень хотелось бы конкретики. мне не довелось наступить на какие-то грабли сокнса, а фраза "преимущества мэйка" -- вообще, очень странно звучит.

хотя-бы - простота - преимущество
распостраненность - преимущество

>> и в таких вещах как сборка пректа - лучше, даже нездоровый, >консерватизм чем постоянный трах с дурью
>с одной стороны, верно. с другой -- самый яркий консерватизм -- "мэйк" на батч-файлах cp/m. а что, работали-же люди?

Да ! если нужно просто выполнить cc file.c -o my_prg
то лучше уж скрипт
-- для каждой задачи - свой инструмент

>>пишут программисты - и дождаться что они сделают .....
>В том то и дело - для себя делают, т.ч. надежды ест
надежда всегда есть, но не всегда оправдывается

Я за скунса

У нас был проект который под Лином и Вендой был (несколько либ, и несколько приложений) Так он собирался без мучений на лине под i386 + три кросса, и Венду (как под VS2003 так и под VS6.0)

Все работало без балды. И никто нифига не тюнил (хотя пожалуй двух одинаково засетапленых машин и небыло даже). Все что надо определялось и цеплялось само. Это был цирк в хорошем смымле слова.

Пастернака не читал но осуждаю

>хотя-бы - простота - преимущество

Простота?! Это вы об этом ужасе, что make своим синтаксисом считает? IMHO даже cons понятнее, хотя я и не любитель пёрла...

>распостраненность - преимущество

Это беда. Оффтопик, знаете ли, тоже очень распостранен. А питон - это уже фактически стандарт.

>> распостраненность - преимущество
> Это беда. Оффтопик, знаете ли, тоже очень распостранен. А питон - это уже фактически стандарт.

так оффтопик значительно лучше чем scons ..... :)))))
а пайтону до стандарта еще раком, раком .....

>так оффтопик значительно лучше чем scons ...

Прелесть

>а пайтону до стандарта еще раком, раком .....

Будьте добры, покажите дистрибутив без питона. Кстати, на чем, по вашему, всякие модные редхатовские конфигурялки и тд написаны?

Scons - пионерам, GNU Make - наше все.

Пробуем trmake:

http://www.cs.bgu.ac.il/~orlovm/trmake/

>>Будьте добры, покажите дистрибутив без питона. Кстати, на чем, по вашему, всякие модные редхатовские конфигурялки и тд написаны?

мил человек
для make у меня есть posix:
The Single UNIX Specification Version 3:

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.
NAME
make - maintain, update, and regenerate groups of programs (DEVELOPMENT)

а для Python ?
а для scons ?

И наверное у тебя есть патчь для гну мейка чтобы он этому стандарту соответствовал?

python плавно в lsb пролезает.

Ага, и будем вечно таскать на себе эти замшелые традиции, охраняемые злобными жрецами (дитяти, того, не трож!) :) Прогресс он на то и прогресс, что старые стандарты исчезают под влиянием новых изобретений.

Насчет lsb здесь правильно сказано^^^. Кстати, если мне память не изменяет, кеды в перспективе будут scons-ом собиратся (поправьте, если ошибаюсь). А XMMS2 именно на сконсе.

>И наверное у тебя есть патчь для гну мейка чтобы он этому стандарту соответствовал?
>python плавно в lsb пролезает.

GNU make conforms to section 6.2 of IEEE Standard 1003.2-1992 (POSIX.2)

надоели в общем
make - простая, системная, стандартная утилита
все остальное от лукавого

>> python плавно в lsb пролезает.

когда пролезет тогда и будете всем рассказывать об этом
а так
приведи модуль/страницу lsb где про python написанно ? ....

>make - простая, системная, стандартная утилита

Дык кто же возражает? Я сам им направо-налево пользуюсь ежедневно. Другое дело, что с гораздо большим удовольствие я бы пользовался scons-ом, т.к. - проще и мощнее (imho добавлю, а то сейчас опять ругань начнется).

>> А то когда мне это было надо я этих доков учитался по самое не могу. >> Проблему я обошёл, но всё таки хочется увидеть красивое и правильное >> решение.

Может оно и не совсем красивое, но не извращённое (и в доке на видном месте лежит):

sources := foo.ucf bar.ucf foo.xx bar.xx
foo.yy: $(sources)
        compiler -u $(filter %.ucf,$(sources)) $(filter %.xx,$(sources)) -o $@

Это было для конкретного случая. Можно (чуть посложнее) задать неяное правило сборки всех yy из ucf и xx:

COMP = compiler
CFLAGS = -u
%.yy: %.ucf %.xx
        $(COMP) $(CFLAGS) $(filter %.ucf,$<) $(filter %.xx,$<) -o $@

Тут есть что улучшить - ucf и xx два раза повторяются.

> GNU make conforms to section 6.2 of IEEE Standard 1003.2-1992 (POSIX.2)

и что? стандарты появляются а) спустя значительное время после появления и обкатки инновации б) путём согласования интересов многих производителей, так что часто, хорошие решения оказываются выброшеными на обочину, в угоду тем, в которые тот, или иной, толстый дядя, успел вложить некий капиталец (см историю X-open, например).

уж не говоря о *минималистиской* природе стандартов семества posix, вообще: если уж ДАЖЕ до позикса не дотягиваем... кстати, линукс, не дотягивает.

>make - простая, системная, стандартная утилита >все остальное от лукавого

gcc (icc/msvc/по вкусу) -- простой, системный компилятор командной строки. IDE, всякие emacs'ы, kdeveloper'ы и т.п. -- от лукавого

>Пробуем trmake: >http://www.cs.bgu.ac.il/~orlovm/trmake/

честно посмотрел. Удивился.

Удивился, что мало кто-то потратил на это своё время, да кто-то ещё и заинтересовался студенческой курсовой по мотивам мэйка. имхо, *на фоне* конкурирующих работ (от tmake'а и boost:jam до собственно, обсуждаемого scons'a), выглядит весьма бледно. А отсутствие универсальности и расширяемости, вообще делает данную работу, бессмысленной. Позволю себе предположить, что автор писатель, не читатель, и с работами конкурентов -- не знаком. не хотел никого обидеть, но... dixi.

>хотя-бы - простота - преимущество

простота чего? сборочной системы мэйка? мне на эту постоту, пардон, плевать, она должна работать, а что у неё в потрахах -- не очень интересно.

простота синтаксиса мэйкфайла? не смешите мои сандалии, это безобразие язык даже не поворачивается как-то классифицировать. рудимент эпохи "16 Кбайт ОЗУ на всё и на всех". >распостраненность - преимущество

для чего? для работы над проектом? на абстрактную распространённость плевать, важна только эффективность и скорость разработки.

для сборки абстрактно взятым сферическим конё... э... пользователем на абстрактном компе в вакууме? так практика показывает, что именно в случае мэйка (+автотулзы, разумеется), иногда возникают непреодолимые сложности. И часто проще заново переписать все правила мэйка (или воспользваться сконсом :), чем разбираться в причинах облома при сборке.

Тот самый случай, когда простота -- хуже воровства. Ибо есть простота на уровне высокого искусства, а есть примитивизм, и смешивать их -- моветон :)

>приведи модуль/страницу lsb где про python написанно ?

lsb-python

с сайта дуй в Application Battery