Опубликован релиз сборочной системы Meson 1.0.0, которая используется для сборки таких проектов, как X.Org Server, Mesa, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK. Код Meson написан на языке Python и поставляется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58382
Опять?
Побежал свои скрипты переписывать срочно! И всем советую!
На раст?
Для безопастной работы с памятью сборочных скриптов.
Учитывая что сборочный скрипт и так может выполнить любые команды в системе? :)
На Модула-2
Тем временем, его уже переписали правильно... https://git.sr.ht/~lattis/muon :)
> Правила сборки задаются на упрощённом предметно-ориентированном языке, отличаются хорошей читаемостью и понятны пользователю (по задумке авторов разработчик должен тратить минимум времени на написание правил).Automake:
bin_PROGRAMS = open-axiom
open_axiom_CPPFLAGS = -I$(srcdir)/src/include
open_axiom_CPPFLAGS += -DOPENAXIOM_ROOT_DIRECTORY="\"$(libexecdir)\""
open_axiom_SOURCES = \
src/driver/main.cc \
src/lib/cfuns-c.cxx \
src/utils/command.cc
Это хорошо, когда проект простой и его сборка укладывается в вызов канпелятора.А если надо кастомный генератор, пре- или пост-процессор вызвать?
Тогда мэйк и автотулзы вообще безальтернативны, лол.Попробуй шаг влево-вправо с этими симэйками, мезонами, дон.
Так вообще лучше не делать - потом новые контрибуторы вас проклинают за это последними словами, очень сложно с такими проектами, гадать из какой там ... вон то вообще вылезает, и тем более как и где это менять.
А сборка проектов на Лиспе?Autotools — легко: http://git.pashev.ru/open-axiom/tree/Makefile.am?h=new-build
Я-то подумал, что ты сборочную систему на Guile наваял.
А паше-вру хлебом не корми, дай своим локалхостом похвастаться.
Не завидуй, у тебя и такого ннт.
>А сборка проектов на Лиспе?Для этого уже есть asdf
>Autotools
Извращенцы
>Вместо утилиты make при сборке по умолчанию применяется инструментарий NinjaЯ правильно понимаю, что расширенный и дополнённый m4 с возможностью парсить грамматики и половиной AWK внутри может взять и заменить все эти meson, ninja, cmake и иже с ними?
может. Вперед, берите и заменяйте
Сборочная система должна поддерживаться средами разработки, например, в части поиска нужных заголовочников. В этом смысле cmake почти незаменима. В частности, имеет поддержку в visual studio (не code).
Хотя админам, которые только собирают, а сами ничего сложнее студенческой лабы не пишут, этого не понять.
Сложнее студенческой лабы в студии очень уж сложно собирать. Одно дело в линуксе вкатить все потребные build deps за пару минут на автомате, пакетным менеджером, и другое - в винде плясать со всем этим.Ну вот например, для начала вы пойдете качать и ставить для вон той штуки питон. А потом и ниндзю заодно. И это вы еще собирать ничего не начали - только сборочное окружение поднимаете. А за время установки студии я так то пару программ посложнее лабы смогу написать, например.
Как здорово что на opennet так много высокопрофессиональных программистов, которые могут за время установки IDE написать пару сложных программу.
Жаль только что написанное они никому не показывают.
> Как здорово что на opennet так много высокопрофессиональных программистов, которые могут
> за время установки IDE написать пару сложных программу.Вьюжлстудия может ставиться буквально день. Скажет что версия дотнета не та и устроит эпопею с несколькими перезагрузками, перегенерацией ассемблей и чем еще. За день можно довольно много чего сделать.
> Жаль только что написанное они никому не показывают.
Как впрочем и "профессионалы" со студией.
> Сложнее студенческой лабы в студии очень уж сложно собирать.Вам человек и говорит, что для отчаявшихся что-то сделать с помощью родной системы управления проектом (solution) Visual Studio напрямую поддерживает систему описания/управления проектом на cmake. Причем, в настоящее время эта поддержка по своим возможностям гораздо шире (и удобнее) родной. Причем, в отличие от студийного подхода, где для компиляции и отладки Линукс/Юникс приложений Вам понадобится заводить отдельный solution со всеми тысячами проектов (а в корпорациях реально бывает и такое и люди там нередко пишут отдельные приблуды для генерации/работы с такими проектами), использование cmake позволит обходится одном cmake-описанием (если оно грамотно составлено, конечно). Причем, и для Винды, и для Линукса/Юниксов поддержка gdb, rsync (они сделали некривой порт на Винду!!!), cmake, ssh и вообще всего-всего доступна прям из коробки. Оно даже воткнет в home на Линукс свои rsync и cmake, чтоб не конфликтовало с системными (на которые тоже можно переключиться).
Да, понимаете, мне в результате оказалось проще на линукс уйти и отделаться от MS и их тулов более радикально. И теперь мне фиолетово есть там gdb или нет. У меня он всяко будет, при том нормальный и устанавливаемый 1 командой из пакетов, заведомо рабочий. Получить нормальную автоматизацию процессов, свободу выбора рабочих инструментов и отсутствие подлян и агрессивного навязывания якобы-правильных путей - это круто, что ни говори. Майкрософт это не умеет, хоть там как. Плохой вендор. Когда вам кажется что это не так, вы просто чего-то не заметили. Рабство и галеры у них в крови.Это даже если забыть о том что более-менее разлапистый проект в линухе элементарно билдуется раза в три быстрее. А я так то не маклауд, чисто технические действа ждать в разы дольше чтобы просто узнать результат правки мной вон того кода.
А так - ну да, cmake штука нормальная. В линуксе, с нормальным софтом, он "просто работает" и вон теми топиками заморачиваться вообще не приходится. И ничего оно мне в линуксе никуда не втыкает, если какой-то софт удумает мне ssh или rsync в обход системного пакетника ставить, будет объявлен бэкдором и разослан всем аверам, сугубо за бэкдорообразную активность. Потому что легитимному линуксному софту нет совершенно никакой причины этим всем заниматься. Это какая-то левая подозрительная активность. Мягко говоря. Еще более левая чем вон тот бэкдор в клаве.
Ох, спасибо, конечно, но для меня это классический "too little and too late": я на линукс ушел и от инструментов MS избавился, мне уже не актуально. Пусть этим счастьем кто-нибудь другой наслаждается. Как и установкой внесистемных rsync с ssh'ем, с моей стороны такая активность софта крайне не приветствуется.И я не понимаю что значит "конфликтовать с системным ssh". У меня просто нет таких проблем. Если это именно программа, она там вообще на самом деле либу ssh или rsync на самом деле так то хотела, а не внешнюю программу, если прогер это не понял тем хуже для него. И прописать поиск либы в cmake и правда несложно, а дальше это проблемы юзера и системы где они эту либу достанут (в пакетном менеджере если это линукс, разумеется). В винде разумеется установка доп либ канительнее.
Сборочная система должна поддерживаться средами разработки, например, в части поиска нужных заголовочников. В этом смысле cmake почти незаменима. В частности, имеет поддержку в visual studio (не code).
Хотя админам, которые только собирают, а сами ничего сложнее студенческой лабы не пишут, этого не понять.
О господи. Не надо. Это конечно был хороший инструмент в 1977, но сейчас-то зачем? Древние проги поддерживать разве что, для которых переход на meson/cmake/scons и другие более вменяемые вещи попроще будет.Каждый раз, когда я открываю очередной .ac файл, который генерирует шелл-скрипт, который генерирует Makefile, который наконец собирает программу, хочется выть. Даже не из-за лишнего промежуточного шага. Разобраться в этой мешанине сложнее, чем даже в CMake, а он тоже не сахар.
Честное слово, даже если бы кто-то написал мелкую служебную программу на С++, которая компилируется в одну строку и потом сама вызывает компилятор в нужной последовательности, это уже было бы лучше, чем M4
Я тебе официально запрещаю это делать.
Конечно, если дополнить макропроцессор общего назначения половиной awt и возможностью парсить, то он знаменит не только костыли meson, ninja, make, но и вообще всё.
Странно что вы со сих пор это не сделали
Чтобы собрать Meson нужно Ninja. Чтобы собрать Ninja нужно что? make? Дальше что? Чтобы собрать make нужно GCC, чтобы собрать GCC нужно autotools, нужно clang, нужно cmake и тд.
Яйцо в зайце, заяц в утке, игла в яйце. Чтобы собрать систему сборки, нужно собрать систему сборки.
Нет билять, только Cmake стал более менее стандартом, начинается зоопарк, закопайте это как можно быстрее. Cmake по синтаксису полное говно, кривой косой, но похрену на это все, на скорость, унификация на порядок важнее. Пусть будет самое кривое решение что может быть, но одинаковое у всех и единый репозиторий библиотек. или два.
Нет уж, кривое ненадо. Надо человекочитаемое.
>самое кривое решение что может быть, но одинаковое у всех и единый репозиторий библиотекУ меня на работе есть один такой, смешно тужится передать свою работу на других, когда выясняется, что назначенные для всех других его сортом людей стандарты не работают даже для него.
А потом выясняется, что стандарты-то уже были, просто кто-то тянет одеяло на себя. Вы перетянули, а потом перетянули уже за вами. Круговорот одеяла продолжается, а пока вы его тасуете с важным видом, разговорами про бизнес вэлью, аджайл, энтерпрайз, скрам и тому подобные софт скиллс, надувая щёки, всерьёз заставляя других учить очередную прорывную мегатехнологию, кто-то просто берёт и пользуется такими немодными инструментами из семидесятых, которые просто работают и для сборки которых не приходится искать именно ту самую тридесятую версию питона.
Просто современные программисты не способны освоить простые понятные и надёжные средства из семидесятых. По этому вместо того чтобы дополнить m4, они изобретают очередной бесполезную сборочную систему типа cmake.
> только Cmake стал более менее стандартом, начинается зоопарк#16527
zhus> У меня есть смутное подозрение, что как только технология отлажена, стабилизировалась, перестает вызывать проблемы и вопросы у пользователей, так сразу она объявляется устаревшей, неразвивающейся и ненужной. И стройные ряды идут героически выкорчевывать то, что не так давно не менее героически взрастили.
Просто с ростом числа применений становится очевидно, что технология хлам и никуда не годится, а значит, пора бы сделать новое и лучше, устранив давно висевший технический долг. Пользователи же в общем случае будут жрать любой кал и просить добавки -- не показатель. В случае с cmake, он взлетел только потому, что всё остальное для кроссплатформенной сборки было ещё хуже и неудобнее, но писали его явно содомиты (в плохом смысле слова). А то, что устаревший хлам впадает в запустение -- вполне логично. Прошлые участники уже разочаровались и ушли в монахи, а новые пойдут туда, где лучше. Ситуация, когда все силы сообщества расходуются на несколько копирующих друг друга проектов, может быть намного хуже, чем когда все заинтересованы в доработке лучшего решения.
Что угодно лучше, чем смаке, даже баш-портянки
>After exactly 10 years, Meson 1.0.0 is out
>The first ever commit to the Meson repository was made 10 years ago to this day. To celebrate we have just released the long-awaited version 1.0.Красота-то какая)))
> Красота-то какая)))В честь
Десятилетнего юбилея
Нашего современного проекта
Объявляем выпуск круглой версии, ура!
> Dependencies
> Python (version 3.7 or newer)Ненужно
От таких muon помогает.
Он поддерживает сборку под Андроид и Айос?
это всё Meson'ы
> Правила сборки задаются на упрощённом предметно-ориентированном языкеЗачем, могли бы просто использовать питон, один фиг оно на питоне
Питон слишком сложный для типичного пользователя сборочных систем, ну и потом, ограниченная функциональность это нормально, да и нет привязки к яп.
> Правила сборки задаются на упрощённом предметно-ориентированном языке
> да и нет привязки к яп.Ну-ну...
Язык описания не язык программирования.
А декларативное программирование не программирование.
> А декларативное программирование не программирование.Ты всё правильно понял. Я всё ещё считаю, что пролог не ЯП в полном смысле этого слова. Не более, чем sql.
Программирую на HTML что я делаю не так?
Перепутал верстку и программирование, мелочи какие. Вот конкретно HTML вообще не язык программирования. По определению - markup language. Он вроде вообще не тюринг полный. Если взять JS, ну, ок. CSS - с большим натягом еще можно засчитать, но он отдельная штука.
На самом деле я не вижу проблем называть какие-то узкоспециализированные языки программирования языками программирования, даже если на них нельзя напрограммировать всё что взбредёт в голову. А такие есть не только декларативные.
лично тебе разрешаю использовать клон meson на сях: https://github.com/annacrombie/muon
> клон meson на сяхНу вот это точно фиг знает зачем нужно когда есть Cmake.
В смысле зачем? Билдить проекты с этой билдсистемой без всяких питонов-электронов и тем более заморочек на тему правильности версий оного.
> Зачем, могли бы просто использовать питон, один фиг оно на питонеWAF, чтоли, так пробовал. Или скунс. Получилось совсем уж лютое. А так вон muon есть, на сишке, реализует этот же DSL-язык, сборочных зависимостей минимум. Вот так оно уже ничего :)
А разгребать проект где кто-то типа тебя сборочное окружение сдобрит креативом на питоне - удовольствие сильно ниже среднего, уже стартовые скрипты так порулили, вот спасибо.
Еще меньше удовольствия подбирать версию питона на ту которая сможет забилдить вот именно эту программу, этой версии. А bisect бага сделать - питонист вообще застрелится, потому что мотаться между 5 подверсиями питона он все же при бисекте бага устанет.
Да что вам все этот питон уперсято? Невозможноже читать его как только код больше страници.
Так ты не читай ты пиши.
Каким образом фигурные скобки решают эту проблему, если когда блок кода больше страницы всё равно вторую фигурную скобку не видно на одном экране?
> Да что вам все этот питон уперсято? Невозможноже читать его как только
> код больше страници.Отступ в 2 пробела не делай или линейку прикладывай. А вообще если фигурные скобки не учитывать, то в с-подобном языке у тебя точно такое же форматирование кода. Так что не придумывай.
>в проекте MesaТак вот для чьих нужд эта система сборки создавалась!
>>в проекте Mesa
> Так вот для чьих нужд эта система сборки создавалась!Да это гномеры, мерзкие типки превратившие нормальный тулкит в жуткое тормозное и непотребное месиво которым пользоваться невозможно.
А это тут причём?
> А это тут причём?Да это примерно та же клика и их дружбаны редгадовские. Было бы круто если б IBM вышибли весь этот мерзкий хайпожорский сброд с треском.
> Предложены новые операторы "in" и "not in" для определения вхождения в строку подстрокиМежду прочим, это встроено в unix shell 😂
Почему бы просто не писать сборочные скрипты на Unix shell?
Настоящему программисту способному писать на любом соответствующем Тьюрингу языке, эти cmake, mesone, make, Gradle и прочие, не нужны
Да пожалуйста:AC_MSG_CHECKING([for Lisp flavor])
oa_lisp_impl_type=`echo '(lisp-implementation-type)' | $OA_LISP 2>&AS_MESSAGE_LOG_FD`
AS_CASE([$oa_lisp_impl_type],
[*"SBCL"*], [oa_lisp_flavor="sbcl"],
[*"GNU Common Lisp"*], [oa_lisp_flavor="gcl"],
[*"Embeddable Common-Lisp"*], [oa_lisp_flavor="ecl"],
[*"CLISP"*], [oa_lisp_flavor="clisp"],
[*"Clozure Common Lisp"*], [oa_lisp_flavor="clozure"],
[AC_MSG_RESULT([unknown])
AC_MSG_ERROR([unsupported Lisp])])
AC_MSG_RESULT([$oa_lisp_flavor])
Это m4 а не shell.
А Вим не текстовый редактор, ага.
Unix shell?
Это трудночитаемые скрипты напоминающие Perl?
Спасибо, но не надо.
Лучше уж на PHP.
> Почему бы просто не писать сборочные скрипты на Unix shell?Потому что сперва придётся написать на нём движок зависимостей.
Осильте уже http://www.gnu.org/software/make/manual/make.html -- там не так уж далеко от корки до корки, местами даже с юморком: "Backslashes that are not in danger of quoting ‘%’ characters go unmolested" ;-)
Заодно чуть познакомитесь с ФП, а это и на шелле бывает полезно понимать.
Кашерный мэйк нужен был только для одного:цель: зависимости
что нужно сделать, чтобы из зависимостей сделать цельВсе остальное от лукавого.
А теперь собери с этой парадигмой что-то сложнее hello world. Что, запыхался? А мы даже не начали динамические зависимости и генераторы кода разбирать.
А не надо просто из исходников собирать целую операционную систему типа Андроида за раз. Собираете помодульно и будет вам счастье.
так Meson/Cmake/m4/прочее и нужно, чтобы автоматизировать помодульную сборку
Генераторы кода вообще такая штука которой лучше не пользоваться в общем случае. Во избежание подыхания проекта, в котором никто кроме оригинального автора не разобрался, видите ли. Потому что желающих раскуривать такой полет мысли потом может элементарно не найтись.Есть очень сильно некоторые исключения, но они редкие, явно не про посетителей опеннета, и вообще-то прекрасно решаемы даже антикварными тулсами типа мэйка и прочих флексов с бизонами. Если этим пользоваться для того для чего оно реально имеет смысл. А в случае анонимусов с опенната это приводит к одноразовому проекту с периодом полураспада в пару лет, потом это никто майнтайнить уже просто не может или не хочет.
> А теперь собери с этой парадигмой что-то сложнее hello world. Что, запыхался?
> А мы даже не начали динамические зависимости и генераторы кода разбирать.Вы не начинали, а я make приспособил для mkimage-profiles, скажем. Понятно, что настоящий программист изобразил бы DSL (и потом остаток жизни его развивал, поддерживал и документировал) -- как и php-образность в плане близости кода и содержимого. Но это мы оставим разбирать уже потомкам :]
> для сборки .. systemd, GStreamer, Wayland, GNOME и GTKВсё ясно, закрываю вкладку...
Мыши плакали, кололись, но продолжали есть кактус (c)В виде мезонов, смаков, маков, нинзей, автотулзов, вместо того чтобы просто взять Qbs.
Питоняка, генерирующая мейкфайлы... И чем оно лучше той же смаки. Теже сорта сами знаете чего, только в другом фантике.
Треш и угар, чтобы собрать приложение, помимо конпелятора, нужно поставить тонны всякой дичи и превратить систему в помойку.
> просто взять QbsКогда дело касается сборки, просто не бывает, сынок. И зачем ты предлагаешь нам qtшную систему сборки?
> Питоняка, генерирующая мейкфайлы... И чем оно лучше той же смаки
Второй уже оброс легаси поуши так, что появился modern cmake. И какая тебе разница поставить питон или autotools?
> Треш и угар, чтобы собрать приложение, помимо конпелятора, нужно поставить тонны всякой дичи и превратить систему в помойку
Только проснулся? Это последние лет 20 происходит
Ты явно проспал последние лет так 90, если считаешь, это происходит всего 20 лет.
> Ты явно проспал последние лет так 90, если считаешь, это происходит всего
> 20 лет.Дед, опять таблетки забыл принять? Напомню тебе, что они у тебя под перфокартами лежат.
> Когда дело касается сборки, просто не бывает, сынок. И зачем ты предлагаешь
> нам qtшную систему сборки?А чем, тебе, дядя, не угодило то что ее кутешники разрабатывали?
> Второй уже оброс легаси поуши так, что появился modern cmake.
Угу, угу, такой он модерн, что прям глаза вытекают глядя на это.
> И какая тебе разница поставить питон или autotools?
Ненене, ты не утрируй, надо поставить: питон + нинзя, или автотулся + маке. А если дело на оффтопике - то там вообще заморачиваться с Msys2 и прочим...
UPD: И у нинзи - о божечки, ограничение на 260 символов для имен/путей к файлам. И если у тебя, дядя, ПОДЛИННЕЕ - то это твои проблемы (размер - имеет значение).
> Только проснулся? Это последние лет 20 происходит
ИМХО, просто программисты - мягкотелые никчемные существа, безвольные тряпки - жрут то что им дают. ))
Вот поэтому так ничего нового и хорошего не прижилось, удивительно даже как то, вот ну правда, без обид. ))
> А чем, тебе, дядя, не угодило то что ее кутешники разрабатывали?Ты предлагаешь маргинальную поделку взамен. qtшники завтра бросят ее как qmake и что ты будешь делать?
> Ты предлагаешь маргинальную поделку взамен.А мезон и смаке - не маргинальные поделки?
> qtшники завтра бросят ее как qmake и
> что ты будешь делать?Да они бросили уже давно ее, и это хорошо (теперь пилится сообществом).
А вот китваровцы/мезонщики (или кто там мезон конопатит?) бросят свои маргинальные поделки и что ТЫ будешь делать тогда?
> И какая тебе разница поставить питон или autotools?Ему, может, и никакой. А вот меня не слышавшие про бутстрап (который раскрутка, а не бегамайты этсамого) "современные разработчики" порой огорчают.
Автокрап в этом плане на две головы лучше продуман со своей стадийностью.
>> И какая тебе разница поставить питон или autotools?
> Ему, может, и никакой. А вот меня не слышавшие про бутстрап
> (который раскрутка, а не бегамайты этсамого) "современные разработчики" порой огорчают.Собрать gcc => собрать autotools => запустить autotools.
Собрать gcc => параллельно [собрать python, собрать ninja] => запустить meson.Разница только во времени сборки. Учитывая, что далее будет собираться нетривиальный софт - это минор.
> Разница только во времени сборки.А также в том соберется ли питон, со всей его разлапистой кучей барахла вопрос не праздный, особенно для нетипичных платформ. И при том еще не абы какой версии. Автотулсы в этом плане сильно проще.
И кстати в многих программах, как минимум в релизах, configure уже сгенеренный лежит. Для его пуска достаточно хоть какого-то шелла. И все. А дальше оно уже там расскажет чего ему не хватает. Чем оно и круто.
autotools в отличие от модных современных молодежных недоделков НЕ НУЖНО запускать "чтобы собрать приложение" - это инструмент _разработчика_ того приложения.Чтобы просто собрать (или даже непросто, а поменяв что-то в исходнике) нормальный проект (не мусор с гитшлака) - нужен _только_ posix-совместимый шелл. Потому что запускается им готовый configure. Пересобирать его перед каждым запуском - не нужно, родной!
Другой вопрос в том что миллионы тестов по умолчанию, которые делает этот скрипт - давным-давно стали бесполезны. Потому что autotools изначально был не для неумеющих в make, а для тех кто хотел писать переносимый софт.
Сегодня это делать - разучились начисто, а автоматизировать дефайны для with/without можно было бы скриптом, работающим пару секунд от силы.
> нужен _только_ posix-совместимый шелл.И совместимый Make. То есть по факту разница в смене shell => python и make => ninja. Поэтому деды ворчат?
> И совместимый Makeлогично, это генератор мэйкфайлов.
При этом gnu make имеет _ноль_ посторонних зависимостей (и да, готовый configure в релиз положить не забыли) и вот там-то autoconf использован по прямому назначению - он по сей день собирается и иногда работает даже на совсем не posix-совместимых платформах, причем для этого не надо ничего делать тебе самому - даже если авторы никогда и не собирались ту платформу специально поддерживать.
>> И какая тебе разница поставить питон или autotools?
> Ему, может, и никакой. А вот меня не слышавшие про бутстрап
> (который раскрутка, а не бегамайты этсамого) "современные разработчики" порой огорчают.
> Автокрап в этом плане на две головы лучше продуман со своей стадийностью.Не забывай, что для autoconf нужно собрать perl
$ apt-cache show autoconf | grep Depends
Depends: perl (>> 5.005), m4 (>= 1.4.13), debianutils (>= 1.8)
> Второй уже оброс легаси поуши так, что появился modern cmake. И какая
> тебе разница поставить питон или autotools?Потом окажется что питоняка как обычно окажется какой-то не той версии, так что вот вам тут по...ся завернули на ровном месте. Или того хуже, окажется что и версия сабжа не та, и вот мелкий квест на 5 минут оказывается длинная эпопея. На третий день траха с билддепсами вам это надоест, вы поймаете просветление, просто скажете gcc src/*c -o program - оно счастливо соберется за 20 секунд и проблема отпадет естественным методом. С мезоном довольно часто работает как-то так, да. Зачем нужна такая автоматизация билдовки софта - вопрос номер два.
> просто скажете gcc src/*c -o program - оно счастливо соберется за 20 секунд и проблема отпадет естественным методом.Свой хеллоу ворлд под локалхост можешь собирать так, никто не спорит. В реальном мире есть зависимости, опции сборки и больше одной платформы (на некоторых из которых gcc не вариант).
> Свой хеллоу ворлд под локалхост можешь собирать так, никто не спорит.На удивление, так собирались весьма здоровенные проекты, когда вон та порнография утомляла.
> В реальном мире есть зависимости, опции сборки и больше одной платформы (на
> некоторых из которых gcc не вариант).В реальном мире иногда бывает так что билдисистема создает больше проблем чем решает. А конкретно хрень на питоне еще и просто непортабельна на кучу платформ, если уж мы об этом. А там еще потом закидоны с версиями окажутся и проч.
p.s. я так то поболее всяких хелловорлдов и не только под всякое разное билдую. Правда gcc там обычно все же есть, проприетарную пакость я не жалую.