>>вследствие чего дропается поддержка тех или иных архитектур?..
>
>По-моему, ни одной ЖИВОЙ ныне архитектуры они еще не задропали. Во всяком
>случае - лично я при всей своей любви к экзотичным и
>кроссплатформенным архитектурам проблем на себе не ощутил. Obsolete Systems
Support for a number of older systems has been declared obsolete in GCC 4.0. Unless there is activity to revive them, the next release of GCC will have their sources permanently removed.
All GCC ports for the following processor architectures have been declared obsolete:
* Intel i860
* Ubicom IP2022
* National Semiconductor NS32K
* Texas Instruments TMS320C[34]x
Also, those for some individual systems have been obsoleted:
* SPARC family
o SPARClite-based systems (sparclite-*-coff, sparclite-*-elf, sparc86x-*-elf)
o OpenBSD 32-bit (sparc-*-openbsd*)
По аналогичным причинам часть архитектур в OpenBSD вообще GCC 2.95 собирается. Это, конечно, далеко не стоковый GCC 2.95, а с бэкпортами и локальными улучшениями, но всё же.
>Кроме того:
>1) Заявы такого плана от опенбсдшника выглядят на мою имху довольно лицемерно.
>Просто потому что я как-то не вижу опенбздей на огромном количестве
>актуальных платформ отличных от х86. В воздухе пахнет двойными стандартами, уж
>извините за честность. Выглядит так как будто проблему откровенно высосали из
>пальца и занимаются борьбой с ветряными мельницами. Уж проприетарщики и то
>вон юзают себе gcc в своих тулзях и не трындят.
Вы, видимо, о тех, кто парится на тему одной-единственной собственной платформы. А не о тех, кто заботится о кросс-платформенности. Думаю, вы понимаете разницу. :)
>2) Проблемы юзеров вымерших архитектур мало кого волнуют кроме них самих. Некромантов
>в природе немного и никто не обязан тратить свои силы на
>обслуживание их трупиков. Если им надо - пусть сами и обслуживают.
>А кому надо какойнить M68K или что там еще, если его
>можно найти только в музее политехники да при большой удаче где-то
>в старом хламе?
Тоже подход, согласен: объявить архитектуру устаревшей и дропнуть, если силы не позволяют её тянуть. А кто-то не разделяет такую точку зрения, вот и всё. Или разработчики GCC — истина в последней инстанции? :) Кому-то и SPARC актуальны…
>3) А, собственно, упомянутые компилеры поддерживают больше архитектур? Не чисто номинально, а
>как с GCC чтобы взял да и сбилдил готовые бинари. И
>не через 15 лет а сегодня, блин. Через 15 лет бинари
>под сегодняшние ARM или MIPS никому нафиг будут не нужны т.к.
>выйдет новое поколение железок, пардон.
Да никто и не спорит, что сейчас GCC — лидер, вы чего??
>>Тянуть самостоятельно GCC, боюсь, не всякая средняя софт-контора сможет. :)
>
>Могу показать штук пять вендоров чипов которые под свои камни официально сватают
>GCC как бесплатнй тулчейн для разработки под их чипы. А ваши
>супердуперкомпилеры смогут похвастаться хотя-бы работоспособной поддержкой этих архитектур?
См. выше про одну-единственную архитектуру.
>> Насчёт же озверения — у CLang есть все шансы потеснить GCC;
>
>Ну, как бы, посмотрим. Пока что - лично я не вижу причин
>для его тотального успеха. Он делается Эпплом, все разработчики - в
>Эппл. А раз так - вектор развития будет такой какой удобен
>Эпплу. А остальные - так, постольку поскольку.
К слову, разработчики != коммитеры. Да и среди коммитеров ситуация уже далеко не столь однобокая, гляньте сами: http://llvm.org/developers.cgi . Может, конечно, часть этих товарищей стесняется рассказывать, где работают, на своих персональных страничках. ;)
>>или иных компиляторов. Да и вообще проблемы с переездом обычно возникают
>>только в очень крупных проектах, либо крайне специфических (заточенных под конкретную
>>платформу) и юзащих всевозможные хаки направо и налево. Так что дело,
>>в общем-то, за конфигурялками. :)
>
>На самом деле - попасть на трах легче легкого. Скажем знакомые бздуны
>вечно в позе рака с слегка кастомными версиями софта на которые
>наложены добавочные патчи под конктретные местечковые нужды, которые никому кроме местных
>как-бы и не нужны а потому отсутствуют в "майнлайн" версиях программ.
Если вы про ситуации, когда в составе проги А идёт кастомизированная версия проги Б, то это, вообще говоря, изначально не слишком open source way. Мало того, что разработчикам дистрибутивов приходится дублировать работу по проверке работоспособности соответствующего кода, так ещё и merge из апстрима (в т.ч. серьёзных багфиксов и секьюритификсов) зачастую запаздывает. В *BSD обычно просто делают ту работу, которую должны были бы сделать разработчики обеих прог…
>При этом у тех кто юзает пингвинов как правило все просто
>компилится и работает, аж скучно.
Дык оно и тут обычно компилится, и даже работает, если ручками собирать. Просто это криво.
> А бздуны эпично сношаются с закидонами древних GCCей и прочая.
Вот, а тут есть такой шикарный шанс перестать это делать — поиметь всегда свежий компилятор, которым всё собирается.
> А clang и прочая они вообще в таких случаях постреляются нахрен.
На данный момент да. Только чего вы заводитесь, и откуда вдруг такая трогательная забота о BSD-шниках? :)
> Впрочем, как говорится "каждый человек сам трындец
>своего счастья". Посему удачи чувкам, ага. Правда Эпплу думается пофиг на
>все проблемы кроме своих. И эппл использует в своей деятельности ажно
>x86, x64 ну и может быть еще ARM. Аж три архитектуры
>как максимум. При том только сильно некоторые их подмножества. А остальное
>Эпплу пофигу а всякие там бздуны как обычно не осилят.
Нет, я с вас валяюсь: когда крупная контора поддерживает, условно говоря, BSD-проект, то она это делает по совсем другим причинам, чем когда другая контора поддерживает GNU-проект. Причина всегда одна и та же: бабло. Если Apple считает, что широкая популярность LLVM пойдёт им на пользу, они будут эту популярность поддерживать, вот и всё. Иллюзий насчёт этой корпорации никто не питает, но уважение за то, что они хорошего, всё-таки, делают, они тоже заслуживают, давайте уж будем справедливыми, а?
> Если уж они порты то работоспособные выпустить до тотального устаревания платформы не
>успевают, представляю себе что там будет с компилерами. Тут вон Толстый
>(Тролль) недавно выдал мыслю что Clang-ом занимается кроме Эппл аж 1
>сторонний разработчик. Уж не знаю насколько это трололо приврало, но если
>не приврало - тогда все весьма уныло - удачи в приссасыванию
>Эпплу, ага.
Это уже весьма старая новость, повторюсь, по результатам беглой пробежки страницы http://llvm.org/developers.cgi , могу констатировать, что всё не так печально.
> А лично мне Эппл внушает сильно меньше доверия чем
>разработчики GCC. Дело в том что у разработчиков GCC нет нужды
>загнать мне свои супер-пупер компьютеры и операционки по тройной цене. В
>отличие от эппла.
GCC steering committee members
The steering committee consists of the following members. The best place to reach them is the gcc mailinglist.
* Joe Buck (Synopsys)
* David Edelsohn (IBM)
* Kaveh R. Ghazi
* Jeffrey A. Law (Red Hat)
* Marc Lehmann (Technische Universität Karlsruhe)
* Jason Merrill (Red Hat)
* David Miller (Red Hat)
* Mark Mitchell (CodeSourcery)
* Toon Moene (Koninklijk Nederlands Meteorologisch Instituut)
* Gerald Pfeifer (SUSE)
* Joel Sherrill (OAR Corporation)
* Jim Wilson (CodeSourcery)
То есть две трети людей, определяющих ключевые моменты жизни GCC — действуют в интересах своего бизнеса. К сожалению, список разработчиков GCC почему-то недоступен (странная скрытность), но, подозреваю, там ещё веселее. :)
>>PCC делает ставку на быструю компиляцию надёжного кода, а не на поддержку
>>всего на свете. :)
>
>Есть только одна проблема: если компилер не поддерживает нужную архитектуру - толку
>от его "быстрой копиляции надежного кода" оказывается ... ровно ноль.
Вот и пилят. Вам жалко, что ли? Или вы предпочитаете монополию на рынке? :)
> А изучать десяток разных тулчейнов тоже как-то удовольствие на любителя. Изучить один
>тулчейн, его особенности, управление кодогенерацией и прочая - примерно в два
>раза проще чем изучить два тулчейна. Прикиньте, а? Ну конечно же,
>как всегда будет поддерживаться аж целый некроманский i386 да может быть
>x64, спасибо если не криво и горбато.
Ну почему, можно вполне сделать совместимый по опциям командой строки тулчейн. Собственно, llvm-gcc и pcc именно по этой причине поддерживают большую часть параметров gcc. Не поверите — работает. :)
