Альтернативы Make'у

> сконс попросил пистон 2.4, дистрибутивного 2.3 ему мало оказалось.

Это где попросил? Не надо заливать. Миниамльные требования -- питон 1.5.2, ТАКУЮ древность сейчас навряд ли, где можно найти вообще. У меня стоит [gleb@glebook _Compile]$ scons -v SCons by Steven Knight et al.: script: v0.96.90.D001, 2005/02/15 20:11:37, by knight on casablanca engine: v0.96.90.D001, 2005/02/15 20:11:37, by knight on casablanca Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation

прекрасно работает с дистрибутивным (ALT) Питоном 2.3.

> на текущий момент мне надо лить пистон на сервер. нафига?

натегА. хотя бы потому, что это ОЧЕНЬ облегчает жизнь (у меня, например, почти все серверные дела, связаные с управлением -- делаются из питон-программ. Что ОЧЕНЬ облегчает жизнь (сколько часов сэкономлено на одном только отсутствии для шелл--программистов ошибок, типа "не тех" кавычек -- оправдывает ВСЁ!!!)

PS: Коверкать имя *чужого* труда, позволяют себе только или хамы, или люди находящиеся *настолько* накоротке с предметом обсирания... Можно полюбопытствать насчёт ссылок на Вашии труды? Или сразу виртуально вставлять Вам пистон -- ну, вы понимаете, куда?

/GLeb

Короче, подводим итоги - make для профи, а остальное для пионеров, чтобы те и не кричали. Make - это unix way по определению, с возрастом поймете мля.

> Короче, подводим итоги - make для профи, а остальное для пионеров, >чтобы те и не кричали

Не так. мэйк -- система сборки первого поколения (амёбы), ant/jam --второго (динозавры), scons -- третьего (теплокровные). Дикси.

> Make - это unix way по определению, с возрастом поймете мля

никакого специфического вэй не существует по определению...

/GLeb

>ИМХО, это путаница ежа с ужом

IMHO здесь как раз путаницы нету. Путаница возникает когда человеку надо на сервере зачем-то питона апдейтить. (смотри на пару постов выше)

> Питон, тот же самый рантайм, только вид сбоку

Сбоку - уже не тот же самый. Для того, чтобы запустить прораммку надо дополнительно устанавливать питона. Или апдейтить. Если не жалко места на диске и производительности, то хотя бы свои усилия жалко. сравним: скунс нативный: требования: linux kernel 2.0, так уж и быть glibc 2* скунс питоновский: linux, glibc, python Получается что надо что-то дополнительно ставить. Зачем спрашиватеся? Потому что разработчик любит питон? Я питонов тоже уважаю, но не до такой степени чтобы на систему без явной необходимости ставить. Повторяюсь, сборка скажем Ц кода не должна требовать интерпретатора питона, это не совсем логично

> где же тут совершенство?

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

> особенность питоновских программ -- исчезающе малый >процент ошибок на 1000 строк кода

Я ничего не имею против питона лично. Более того, я уважаю этот язык и считаю его хорошо продуманным. Но то, что питон не производит native code executable мешает установке скунса на мою систему. Каким бы хорошим скунс не был.

> виде одного "нативного" и низкоуровнего(!) модуля > система -- будет содержать более. чем заметный > процент ошибок

Что касается насчет надежности языка и малого количества ошибок я солгашусь, как это важно, однако питон не единственный язык, есть и другие языки, концептуально не позволяющие программисту совершать ошибки, в частности исходя из этого я предпочитаю pascal (www.freepascal.org) который производит native code, и ulm oberon http://www.mathematik.uni-ulm.de/oberon/ который также является native code compiler

Моя программа if-so http://www.geocities.com/asprayama/if-so/if-so.html написанна на паскале, и откомпилированная статически занимает около 200 кб, однако в ней при малом размере и реализовано достаточно много функций. Работает без интерпретаторов и всякой дребедени одинаково хорошо на RH 5.2 и RHEL 4 ;) Выясняем, что питон не единственный в мире хороший язык. И то, что он надежен не означает что скунса я себе в систмеу установлю, потому как он требует питона. Птотму что повторяюсь, для сборки Ц программы мне не должно быть необходимо ставить питона. И то, что не каждый современный дистрибутив будет работать без питона, перла, и т. д. мне не кажется хорошим знаком. Питон и перл имеют свою сферу однако мне не кажется что линукс система не должна сущсетвовать бе них.

> (у меня, например, почти все серверные дела, связаные с управлением -- делаются из питон-программ. Что ОЧЕНЬ облегчает жизнь (сколько часов сэкономлено на одном только отсутствии для шелл--программистов ошибок, типа "не тех" кавычек -- оправдывает ВСЁ!!!)


Ндяя...
рыдаю...

>Ага, а ответить на конкретные претензии к make (они были выше) мозгов не хватило

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

>Про дурнопахнущее - это про что?

про то что требует ставить пистон на сервер в обязательном порядке

>Зашибись. Отключили мозг, построились шеренгами - и вперед, в светлое будущее!

ага, в цирк монти пайтона

>У меня все-таки свои мозги есть

ну так зачем же ты мил человек призываешь сломать работающую систему и заменить ее на неизвестно что, только потому что ты пистон выучил?

>Видимо, мозгов хватило только на личные наезды.

ну так а что ты хотел? с твоей стороны был не конструктив, а бессвязные вопли на тему "давайте сделаем все так как удобно мне"

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

все. махровый фанатизм. кг\ам. дальше можно не читать

> А это как у врачей. Нет здоровых людей, есть недообследованные.

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

Нормальные разработчики, как известно, BSD стороной обходят.

Если это Unix-way - то я против такого way. Anjgre!

> Не надо заливать. Миниамльные требования

да да да. также мне тогда и говорили. реальность она знаешь ли упрямая вещь - говорю же, видел своими глазами.

>хотя бы потому, что это ОЧЕНЬ облегчает жизнь (у меня, например, почти все серверные дела, связаные с управлением -- делаются из питон-программ.

да да. у меня тоже самое на перле баше. почему ты считаешь что твоя точка зрения более правильная? перл - это стандарт дефакто (см. cpan.org) а пистон - нет.

>типа "не тех" кавычек -- оправдывает ВСЁ!!!)

типа "не тех" отступов

>или хамы, или люди находящиеся *настолько* накоротке с предметом обсирания

...или люди которым фанатизм от одного из скриптовых языков не выел весь мозг окончательно

>Или сразу виртуально вставлять Вам пистон -- ну, вы понимаете, куда?

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

>scons -- третьего

ба. когда хотя бы 1% софта что я использую будет собираться на пистоновском сконсе, тогда и поговорим. пока это лишь тупиковая ветвь

>никакого специфического вэй не существует по определению

юношеский нигилизм. желаю тебе поскорее повзрослеть

Да нет, таки уж с ежом спутан...

Паскаль -- ни разу не замена и не конкурент Питону. Это аболютно разные языки и идеологии (статическая vs динамическая типизация, наследование и т.п.). Попробуй переписать сколь-либо крупный питон--проект на С++ или О-Паскаль (что, безусловно, возможно)... очень сомневаюсь, что эта работа займёт времени меньше, чем полный цикл разработки питон-проекта (а ведь предлагается простая "перекомпиляция"!), а уж сколько ярких впечатлений гарантировано при переносе -- ух! некоторые вещи без смены идеологии не сделать вообще... Тогда уж надо сравнивать Objtctive-C и Питон (и сразу влететь в значительно менее мощную обработку ошибок), или Питон -- smalltalk, или... неважно, перечислять можно довольно долго. Одно общее -- все динамические языки тащят за собой довольно большой рантайм, хотя и не все реализованы в виде байт-код компиляторов.

Ещё раз: относитесь к питону -- как к рантайму. Если уж очень не хочется ставить полную питон- систему -- нет проблем, воспользуйтесь freeze/py2exe, сконс после конвертации - работает.

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

> все. махровый фанатизм. кг\ам. дальше можно не читать

Не думаю. практика показывает.

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

/GLeb

А вот я буду следить за Торвальдсом :-). Как только он обьявит, что надо SCons'ом ядро собирать (и для вящей совместимости и кошерности еще конфигурялку к ядру на PyGTK напишут), то значит и мне пора задуматься. А пока буду сидеть тихо.

З.Ы. На git, правда, пока не перешел. Инерция, привычка, понимаешь...

>> Не надо заливать. Миниамльные требования

>да да да. также мне тогда и говорили. реальность она знаешь ли упрямая >вещь - говорю же, видел своими глазами.

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

А раз понимаете -- значит врёте... Ну, дискуссия становится неинтересной.

>да да. у меня тоже самое на перле баше. почему ты считаешь что твоя >точка зрения более правильная? перл - это стандарт дефакто (см. >cpan.org) а пистон - нет.

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

> типа "не тех" отступов

опять передёргивание... отступы (кстати да, не самая удачная питоновская фишка) -- отлавливаются ещё ДО исполнения кода. А типичные ошибки шелл-скриптов -- бывают просто разрушительными! И это всем прекрасно известно :)

> вьюноша, свои подростковые сексуальные фантазии

Ой, спасибо, даррррагой! Я и не думал, что так хорошо сохранился...

/GLeb

> А вот я буду следить за Торвальдсом :-). Как только он обьявит, что >надо SCons'ом ядро собирать

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

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

Хотя, по мере переползвания KDE на scons, глядишь -- и остальные подтянутся.

/GLeb

Скунсам, питонам и остальным животным прямая дорога в Бобруйск, а мы make ни на какую пионерию не поменяем, наш выбор unix-way :)

о тебе чтоли?

take a look to netbsd side.....

>Паскаль -- ни разу не замена и не конкурент Питону

Покажите мне где это я позиционировал Паскаль как замену питону? Я вообще не сравнивал языки. Я заметил (смотри выше) что безуслопвно у питона есть своя ниша, но в сборку Ц она не вписывается.

>freeze/py2exe

Подобные решения чем-то напоминают статическую компиляцию. Если есть выбор ставить питон или использовать таким вот образом распространяемые программы то я предпочитаю ставить питон

>>Паскаль -- ни разу не замена и не конкурент Питону

>Покажите мне где это я позиционировал Паскаль как замену питону?

У меня сложилось именно такое впечатление.

> что безуслопвно у питона есть своя ниша, но в сборку Ц она не >вписывается.

я не вижу проблем. Мы всегда работаем в некотором окружении. И для сборки/обточки даже "чистого" C-кода, требуются вещи, от Sea :) весьма далёкие: хотя бы редактор, средства сравнения, хелпы, CVS, наконец!

C питоном и сконсом -- Совершенно аналогичная ситуация. С точки зрения аскета и стороника минимализма -- и то и другое -- лишняя сущность; с точки зрения нормального :) человека -- очередное благо цивилизации, не более и не менее. В конце концов, линотипы-ротапринты-лазерные принтеры тоже отнюдь не нужны с точки зрения поборника чистоты идеи книгопечатания, но почему-то необходимые и достаточные Гуттенберговские прессы -- естественным путём уступили место "явным излишествам".

/GLeb

С точки зрения логики, конечно не кажется нормальным, что для сборки програмы на С++(С) надо использовать питон.

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

На самом деле, многие претензии к make, типа, способа идентификации изменения файла , единное пространство имен, вполне оправданны.

> Кроме того, чем меньше компонент разной идеоологии используется - тем > выше надежность системы, это тоже очевидно

неочевидно, если сторонняя *высокоуровневая" компонента склеивает или контролирует, или (здесь) -- собирает -- компоненты *низкоуровневые*.

PS: привет Геделю и его теоремам :)

/GLeb

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

Конкретный пример у меня был насчет "скриптуемости", пример был с ANT-ом.

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

Ты не покажешь, где я это говорил?

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

Я не предлагал ничего ломать. Ты не поверишь, я даже Питон почти не знаю.

>ну так а что ты хотел? с твоей стороны был не конструктив, а бессвязные вопли на тему "давайте сделаем все так как удобно мне"

Конструктив был. Был пример с макросом ANT. Я посетовал, что ANT - это не Лисп.

>Скунсам, питонам и остальным животным прямая дорога в Бобруйск, а мы make ни на какую пионерию не поменяем, наш выбор unix-way :)

Типичный фанатизм, что тут еще сказать. Кстати, причем тут Unix-way, не просветишь?

Вот именно об этом и речь. С(++) это вполне сознательно достаточно низкоуровневый способ работы. Невозможно понять, как можно совместить низкоуровневую идеологии и высокоуровневую.

В общем случае это сделать невозможно, но для разных практически интересных вариантов это можно делать и использовать.

Редактор это инструмент, а маке это все таки нечто большее.

>Короче, подводим итоги - make для профи, а остальное для пионеров, чтобы те и не кричали. Make - это unix way по определению, с возрастом поймете мля.

Ага, когда маразм в голову ударит :)

а что гуру думают по поводу этого текста:

http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

> Вот именно об этом и речь. С(++) это вполне сознательно достаточно >низкоуровневый способ работы

на здоровье. Если требуется выполнять нечто сильно аппаратно-зависимое или критичное по скорости - памяти -- то да, это низкоуровневый способ *работы*. Но причём здесь сборка?!

> Невозможно понять, как можно совместить низкоуровневую идеологии и >высокоуровневую.

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

Но причём тут сборка?! :)

/GLeb

Попробуем немного огрубить

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

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

Ты бы мог возразить мне гораздо сильнее, если бы сказал, что сплошь и рядом автоматизированные системы создания (компиляторы )кода используются в проектах, ради выигрыша во времени написания проекта, даже на С(++). (например в COM весь RPC код генерируется автоматически, а это хуже вручную написанного кода в среднем раза в 2)

Но я сказал что для практически важных случаев часто используют разные гибриды.

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

И опять скажу просто. Два человека с разным мышлением и поведением , могут делать обшее дело, только договорившись заранее о общих правилах . Что автоматически означает ограничение свободы каждого ради достижения какой то цели.

Такой вопрос:

Человек использует возможности питона в системе сборки. Затем язык делает свой очередной шаг в развитии и вместо старой версии распространненной становиться новая версия. Возможность котурую, использовал человек в своем проекте, в новой версии языка реализовали подругому. Переписывать навороченный питоновый мейк?

> Ура!!! Я запустил MacOSX на писи!!! Инструкцию брал здесь http://grabberslasher.no-ip.com/macosx/

Вот это да! Пришли плиииз скриншот. Очень хочецца Mac OS X. Винда уже поперёк горла... (((

Линукс не готов к применению массового количества пользователей, потому как даже в КДЕ неприятно находиться, невозможно вывести на печать, PHP не работает, а разрешение не удаёцца настроить (у меня максимальное 600x800).

Пользователи выбирают Make, чтобы пакеты независимо собирались.

Разработчики выбирают альтернативы, что выражать свои мысли, особо не задумываясь...

Тому у кого в KDE PHP не работает - сделай доброе дело, получи премию Дарвина!

Вот и я говорю:

>Пользователи выбирают Make, чтобы пакеты независимо собирались. ПРОФИ

>Разработчики выбирают альтернативы, что выражать свои мысли, особо не >задумываясь... ПИОНЕРЫ

(1 /2 ) Извиняюсь, бред какой-то.

> C(++) специально написан, чтобы все делать используя именно его. Так задуманно для эффективности.

Кто сказал? Боюсь, тебя обманули. Более того, двумя строчками ниже, ты сам себе противоречишь. Да господи, что там рассуждать, любой более-менее продвинутый инструмент для работы с C\C++ (всего-навсего, *компиляторами*, не больше и не меньше) -- вовсе не обязаны быть ьнаписаными именно на C/C++. Пример -- Visual Age -- smalltalk, Eclipse -- о же почти ни разу не ++ :) Более того, система сборки вовсе не обязана иметь какое-либо отношение к собираемому проекту. Чот,сосвенно, и наблюдается в классическом мэйке -- вполне тупой программе, которая только и умеет, что ослеживать даты файлов и запускать внешние программы по перечисленным в мйкфайле правилам. Накаком языке реализован мэйк -- никого не волнует абсолютно (собсвтенно, пнервые мэйки, если не ошибаюсь, и представляли собой весьма простые и непритязаельные скрипты). Более того, совершенсвование мэйк-системы,очень долго шло всего лишь по пути совершенствования парсера мэйк-сценария, чтобы уйти от необходимости иметь множество разнообразных мэйков для разных видов работ. От отдельныхмэйков для Си,отдельных для ++ или ObjC и так далее. Но принципиально-то ничего не менялось! Идеология -- не менялась! Всегда одно и тоже -- проверка даты файлов и запуск команд по сценарию, причём даже самый распоследней версии (классический) мэйк -- решительно не "понимает", что делает, а просто выполняет написанные в мэйк-файле наборы команд. А на каком языке написана сценарная система мэйка -- по барабану, в идеологии это ровно ничего не меняет.

...continued...

[ 2/2 ] ...contunuation...

Более того, как только проект становится сколь-либо большим или хотя бы чуть сложнее, чем простенькие утилитки начала 70-ых годов, появляется неустранимый родовой недостаток классических мэйков: проблема зависимостей. Мэйк ни фига "не понимает",что происходит в собираемом проекте, и бремя отслеживания зависимостей ложится на разного рода доп.костыли, отслеживающие эти самые зависимости и опять корректирующие, дописывающие -- явно или неявно -- мэйк-сценарий. В какое угрёбищше это выливается -- нет пролем понять, просмотрев мэйк, сгенерированный аутомэйком+аутотулс для более-менее сложного (даже одноязыкового проекта, например, KDE-приложения! а в реальности сейчас, как правило -- проекты скорее многоязыковые!). Без пол-литры в этом дерьме не разобраться и если что-то пошло не так... не приведи, Боже!

И вот тут на сцене и появляются сборочные системы второго и третьего поколений. Которые не только должны выполнять некий сборочный сценарий, но и делать это осмысленно. Всё. Остальные домыслы -- от лукавого. На каком языке написана сборочная система -- плевать глубоко и с высокой колокольни: система может быть написана хоть на санскрите, главное, чтобы она *пониамала*, что делает. Сконс -- понимает.

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

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

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

Бред, извиняюсь. Какая эффективность? Сборки? Интеллектуальная система сборки всяко делает это лучше, чем примитивные мэйки, сценарии которых часто написаны -- то ли как с бодуна, то ли с перекура. Работы собранного проекта? Ещё больший бред -- какое отношение имеет *сборка* -- к *работе* ?!

На прочее отвечать не буду, извини.

/GLeb

> Человек использует возможности питона в системе сборки. Затем язык делает свой очередной шаг в развитии и вместо старой версии распространненной становиться новая версия. Возможность котурую, использовал человек в своем проекте, в новой версии языка реализовали подругому. Переписывать навороченный питоновый мейк?

Опять бред...

1. на питоне написана *система сборки*. Разработчики которой -- вполне вменяемые люди, и знают, что такое "совместимость снизу вверх".

Это значит, что

1) менять *сценарий сборки* -- тебя никто не заставляет, по определению "старые" сценарии должны сохранять работоспособность. 2) возможныек критические несовместимости -- ложатся на плечи разработчиков системы сборки, а отнюдь не конечного пользователя.

Более того, по секрету тебе скажу -- разработчики Питона -- тоже, вменяемые люди и тоже знают, что такое совместимость снизу вверх. Значит, старые версии системы сборки должны прекрасно работать с новыми версиями языка (но не наоборот, естественно!)

PS: Наконец, в том и прелесть интеллектуальных сборочных систем, им (как правило!) не нужны "навороченые сборочные сценарии". Они достаточно умны, чтобы понимать, как получить конечный результат без помощи человека. /GLeb

> Пользователи выбирают Make, чтобы пакеты независимо собирались.

Неверно. Практика показывает, что при применении стандартного "configure && make && make install", пользователь мгновенно попадает в тупик, как только что-то начинает идти не так.

В случае применеия интеллектуальных систем сборки, нпр, scons, такая беда просто не возникает.

/GLeb

> Опять бред...

Обидно. :( Я ничего не утверждал. Я спрашивал.

Просто кто-то говорил про появляющуюся возможность использовать питон в скриптах. Вот я и спросил.

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

Ты хочеш сказать, что ВСЕ скрипты написаные для 1.x.x работают на 2.x.x?

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

> Ты хочеш сказать, что ВСЕ скрипты написаные для 1.x.x работают на 2.x.x?

Испольщующие *только* базовый функционал -- безусловно. Варниниги -- не в счёт.

/GLeb

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

Может. Крайне маловероятно (так как в норме, используется только базовый функционал и весьма в скромных масштабах), но может.

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

/GLeb

Gleb, успокойся и постарайся получить премию Дарвина.

А вот интересно, а кто-нибудь из тех кто кричит "Скунс ацтой", "Питон --- давить", и т.д. собственно сконс пробовали? И что каждый здесь пишет системы размером с КДЕ, которые должны собираться на 1000000 операционных систем?

Я использую и make и scons, могу сравнить и сделать выбор. Вернее я его уже сделал. Там где у меня уже работает make он и продолжает работать, а во всех новых проектах я использую scons. Даже под Win32/MSVC, т.к. написать нормальный скрипт для сборки проекта в scons-е проще/переносимей (с машины на машину) чем городить огород в гуях MSVC. А кто из тех кто использует make может похвастаться использованием make для сборки проектов MSVC? (Про CMake мне можно не говорить, сталкивался :-) )

По поводу совместимости версий Scons-а/Python-а. SCons работает на всех версиях питона начиная с 1.5.2, а это очень доисторическая версия. И продолжает работать без сучка и задоринки на 2.4.

Если кто-то в своём скрипте использует какую-то фичу, которая будет исключена из языка, то при смене версии он сперва получит deprecation warning, и у него ещё будет несколько лет (от 2 до 5 условно :-) ) на устранение этой проблемы.

И если уж на то пошло, то makefile-ы точно так же зависят от версии make-а, а то что make не меняется (не улучшается), это спорное достоинство.

А вот ещё интересно, кто-нибудь реально использовал Boost.Build?

>неочевидно, если сторонняя *высокоуровневая" компонента склеивает или контролирует, или (здесь) -- собирает -- компоненты *низкоуровневые*.

>PS: привет Геделю и его теоремам :)

Ключевые слова не подскажешь по этой теме? Всего Геделя перечитывать не предлагать :D Но устойчивость больших систем, состоящих из неустойчивых элементов мне интересна :)

чики-пуки тест

Ну тогда попробую написать свою систему сборки с анализом кода...
XML форматом описания(текстовым)....
и усё на C++.