Назовите хотя бы одну причину существования долбанного meson...

автотулзы писались для сборки gcc, и до сих пор с этой задачей справляются

Увы, они с этим отвратительно справляются

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

сам gcc стал жирным и дофига сложным, он иногда плохо собирается и требует патчей в разных случаях. но автотулзы тут ни при чём.

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

Хотелось бы конечно чтобы система сборки такого не допускала

Я не уверен, что описываемое вами - проблема системы сборки. Система сборки гарантирует лишь минимальный чекинг зависимостей: по хедерам и непосредственным исходникам - до соответствующего объектника. Всё остальное разраб должен прописывать руками. Если он, вместо зависимости, где-то вставляет прямой вызов какого-либо сборочного скрипта из саб-прожекта, то всё, здесь ответственность билд-системы заканчивается.

configure – это фактически бинарный блоб

Вообще-то нет, всë читается вполне себе хорошо.

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

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

Это славные традиции, нельзя их нарушать.

Мне нравится эпизод из начала 00-х, когда в libtool запили кривой код для IRIX-а, и когда человека спросили, зачем он это сделал, он ответил, что просто накидал код по описанию из email-а, а сам этот IRIX в глаза никогда не видел и не тестировал там ничего.

А потом этот баг не стали убирать, чтобы не ломать «обратную совместимость».

Аналогично в libtool из-за сраной опечатки (а может и специально, уже не докопаться) всю жизнь поломана совместимость с BSD, и бздуны всю жизнь подкладывают под неё костыли и патчи, чтобы собирать гнутый софт.

Багу не фиксят тоже для «обратной совместимости». (С чем, млять???)

При чем по еще одной славной традиции GNU ломающее изменение был внесёно коммитом, в описании которого оно даже не упоминается.

Учитесь, как надо троллить))

Отсюда

Ты ссылаешься на пи$%ола, которого я 2 сообщениями выше уличил в прямой лжи? Единственная ссылка на «пруф» у тебя ведёт на его комент? Слушай, всё больше кажется, что ты просто троль.

автотулзы писались для сборки gcc, и до сих пор с этой задачей справляются

Увы, они с этим отвратительно справляются

gcc вообще кладезь «гениальных» решений, так что автолулзы в этой галерее наскальной живописи дрочащих на мамонтовые фекалии обезьян смотрятся весьма органично. Начиная с того, что в gcc специально не стабилизирован промежуточный язык (типа LLVM IR), чтобы затруднить разработку тулинга для интеграции с редакторами и IDE (Шмальман очень боялся, что gcc встроят в visual studio, не шучу). И заканчивая тем, что под каждую целевую платформу нужна отдельная сборка gcc вместо того, чтобы просто переключать таргеты передачей ключика в вызов компилятора.

Воистину, гнутые проекты все прокляты. Просто поголовно.

Но при всем этом он намного лучше LLVM/Clang. Генерируемый код лучше, поддержка новых стандартов намного быстрее приходит, и статический анализатор для С реально находит ошибки, и не плюется ложными срабатываниями на каждую строку. Так что в основных моментах они все же не ошиблись, как компилятор он занимает почетное первое место. А вот Clang вполне приличный генератор подсветки синтаксиса.

Начиная с того, что в gcc специально не стабилизирован промежуточный язык (типа LLVM IR)

Вместо LLVM IR у GCC есть libgccjit (там не только JIT, неудачное название просто).

Шмальман очень боялся, что gcc встроят в visual studio, не шучу
заканчивая тем, что под каждую целевую платформу нужна отдельная сборка gcc вместо того

Ну тут так и есть, хотя можно вспомнить -m32/-m64.

Ты ссылаешься на пи$%ола, которого я 2 сообщениями выше уличил в прямой лжи?

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

1. Автолулзы реально сосут;
2. В каждом втором проекте на автолулзах сложнее Hello World реально есть скрипт типа autogen.sh, который реально нужен, чтобы это говно как-то прибрать, и нет, твои костыльные «решения» ни разу не помогут.

У тебя просто автолулзы головного мозга. Вагоны ./configure переполняют твою черепную коробку, не оставляя места для разумных мыслей.

Слушай, всё больше кажется, что ты просто троль.

Я не просто тролль. Я один из самых качественных троллей ЛОРа, ведущий подрыватель жоп модераторского состава и вообще один из самых классных парней тут. А чем ты можешь похвастаться?

Но при всем этом он намного лучше LLVM/Clang.

Даже близко нет.

Вместо LLVM IR у GCC есть libgccjit (там не только JIT, неудачное название просто).

Это круто, но, во-первых, для внешнего тулинга эта хрень практически бесполезна, потому что это только бэкенд. Фронта там нет, анализатор из этого не сделаешь. Оно только для экспериментов с новыми фронтами подходит, да и тут LLVM куда лучше. А во-вторых, уже поздно, LLVM допилили и он работает.

Ну тут так и есть, хотя можно вспомнить -m32/-m64.

У GCC можно одним бинарником генерить код под amd64, arm64 и rv64? Нет? Ну и вот. Даже сраный голанг, прости хоспидя, умеет так. А GCC не умеет.

Хорошо горит, давайте дальше.

Всё так. База.

Даже близко нет.

Очень аргументированно! Clang это буквально инструмент подсветки синтаксиса, он не умеет даже в какую то базовую оптимизацию, то что он постоянно пихает CMOVcc вместо CMP на Intel это хорошо показывает, его инструкционный планировщик студенты заполняют?

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

Ну речь же про LLVM IR, он что, полезен для внешнего анализа?

У GCC можно одним бинарником генерить код под amd64, arm64 и rv64? Нет? Ну и вот. Даже сраный голанг, прости хоспидя, умеет так. А GCC не умеет.

Ну одним файлом ты даже программу для amd64 не соберешь. Я разницы не вижу, писать gcc-arm64 или clang -arm64. Есть какие то отличия, кроме количества нажимаемых клавиш?

Единственная ссылка на «пруф» у тебя ведёт на его комент?

Пруфы лежат в истории коммитов libtool. Сложно, понемаю.

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

Слушай, это всё очень грустно, на самом деле. Вот все эти сравнительно новомодные идеи типа LSP или IR в компиляторе, они все были в гнутых проектах ещё лет 25 назад. Только их взяли и с размаха уе?*:?:ли о стену, чтобы злые проприетарщики не пользовались.

Про GCC IR я выше писал. Были проекты типа gccxml для интеграции фронта из gcc в IDE, чтобы можно было подсвечивать ошибки без необходимости парсить человекочитаемый выхлоп компилятора, только Штальман его предал анафеме и разработка этого заглохла.

Про LSP, задолго до него лисперы в порыве гениальности запилили SWANK для связи Emacs (SLIME) и лисповых компиляторов. Штука в том, что SWANK особо от лишпа не зависел и его можно было с любым язычком использовать. Я использовал SWANK с Ruby лет 12 назад, когда никаким LSP не пахло. И что ты думаешь? Сделал ли кто-то SWANK-сервер из GCC, чтобы можно было быстро из емакса сишний код править? Конечно нет!

Печально всё это. Мы могли бы иметь очень и очень крутые средства разработки под лялексом ещё 20 лет назад, если бы гнудебилы не были толпой дрочащих на мозоли обезьян, назло проприетарщикам морозящих себе тестикулы до гниющей гангрены раз за разом. Что характерно, проприетарщикам от этого особо не жарко и не холодно.

Какой прямой лжи?

В «цитировании» документации с пропуском того, что ему не выгодно. В запугивании всех говноскриптом, который, в последствии, оказался его собственным. Ну и, судя по твоему посту выше, такое он здесь делает регулярно.

Я не просто тролль. Я один из самых качественных троллей ЛОРа

Что ж, тогда я просто не буду отвечать на твой дальнейший бред.

Очень аргументированно! Clang это буквально инструмент подсветки синтаксиса, он не умеет даже в какую то базовую оптимизацию, то что он постоянно пихает CMOVcc вместо CMP на Intel это хорошо показывает, его инструкционный планировщик студенты заполняют?

А плохого-то что? В бенчах у шланга и гцц производительность примерно одинаковая. Какие именно инструкции он пихает, насрать 10 раз. Если тебе важны сами байты, пиши на ассемблере.

Ну речь же про LLVM IR, он что, полезен для внешнего анализа?

Есть вагон тулинга для анализа LLVM IR, дабы не анализировать входные языки.

Ну одним файлом ты даже программу для amd64 не соберешь.

Чо? go build и поехали.

Я разницы не вижу, писать gcc-arm64 или clang -arm64. Есть какие то отличия, кроме количества нажимаемых клавиш?

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

Шланг порой генерирует медленный код и дело тут не в каких-то байтах

https://lists.gnu.org/archive/html/bug-libtool/2002-01/msg00003.html

https://lists.gnu.org/archive/html/bug-libtool/2011-05/msg00007.html

Иди обтекай.

Я разницы не вижу, писать gcc-arm64 или clang -arm64. Есть какие то отличия, кроме количества нажимаемых клавиш?

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

Так что да, силанг показал, что так можно и что это удобно. Почему гнутики не почесались - непонятно.

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

Ты мне сейчас хочешь сказать, что только wandrien в своих проектах использует autogen.sh? Потому что это нихрена не так. Я сейчас работаю над проектом старше меня, который частично собирается автолулзами, и таки там тоже эта срань есть, а вандриена там нет. Эта херота реально повсеместна.

Что ж, тогда я просто не буду отвечать на твой дальнейший бред.

Ты просто завидуешь моему величию.

Анону бы научиться троллить потоньше, чтоль...

Мне подход GCC к кросскомпиляции представляется каким-то тяжким наследием того, что собой компиляторы представляли собой в 70-е.

Хотя это странно, ведь gcc делался с нуля в конце 80-х, начале 90-х, да и исправить давно можно было всё.

Но видимо, особенности майндсета его разработчиков.

Вспомним классику: https://ewontfix.com/12/

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

Про баги libtool они не слышали, про особенности сборки gcc не знают…

Зато у них всё «хорошо работает». Сидя на диване, видимо.

А что сраный fixincludes буквально в каждом дистрибутиве отключается однострочником на sed перед запуском компиляции, это ж еще знать надо такие штуки.

Я так прозреваю, тогда делать отдельный бэк на каждый таргет было модным. Этим многие компиляторы из 80х и 90х страдают. Из того, чем я пользуюсь, GHC и OCaml тоже такие. Хотя в GHC можно через LLVM компилировать вместо нативного бэка, так что это частично упрощает дело.

Вспомним классику: https://ewontfix.com/12/

Replacing VxWorks’s stdint.h, which is claimed to be broken, with one full of incorrect definitions, for example #define UINT8_MAX (~(uint8_t)0) (which, contrary to the requirements of C, is not valid for use in preprocessor conditionals).

/me рыдает

https://lists.gnu.org/archive/html/bug-libtool/2002-01/msg00003.html

И чо? Чуваку объяснили, что система сборки должна линковать с libname.so, который является симлинком на нужный солиб. И совершенно не важно тогда будет, какие там циферки.

Потом ему сказали: «ну хочешь - пофикси», и он пофиксил. Я лично проверил, что в /usr/share/libtool/build-aux/ltmain.sh уже нет этого +1.

https://lists.gnu.org/archive/html/bug-libtool/2011-05/msg00007.html

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

Иди обтекай.

Ну да, тупой школотрон привёл пару рандомных багов 20летней давности, и думает, что его тролинг кому-то интересен. Пожалуй, и тебе больше не буду отвечать. Чего на врунов время тратить…

Имхо, это последствия типичного кода на Си в стиле 70-х, 80-х с кучей #define, #ifdef и extern. Чисто формально у тебя разделение на фронт и бэк вроде бы есть, а по факту – нет, потому что ничего из этого не получится скомпилировать отдельно в объектные модули.

В качестве миниверсии такого подхода можно рассматривать сорцы tcc. Поддержка разных таргетов там только при первом взгляде сделана в виде отдельных .c, которые можно скомпилировать отдельно. А на самом деле — в виде кучи #ifdef .. #elif ... #elif по всему коду проекта.

(which, contrary to the requirements of C, is not valid for use in preprocessor conditionals).

Прямо по больному))

(:

- У тебя нет пруфов!11111
- Вот пруфы.
- Ко-ко-ко! Ко-ко-ко! Ко-ко-ко-ко!

Может это и баг билд-скрипта, но в контексте того, что он предназначен для сборки gcc, подобные баги говорят что всё-же что-то не так.

По какой-то причине они не используют аутомейк, а используют вот это: https://www.gnu.org/software/autogen/

Почему так, и с чем это едят - я вообще не в курсах.

/me рыдает

А над чем ты, собственно, рыдаешь-то?

4.2.2 If

expression is a C expression of integer type, subject to stringent restrictions. It may contain
…
Arithmetic operators for addition, subtraction, multiplication, division, bitwise operations, shifts, comparisons, and logical operations (&& and ||). The latter two obey the usual short-circuiting rules of standard C.

Для gcc’ишного cpp это совершенно валидное выражение.

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

Для gcc’ишного cpp это совершенно валидное выражение.

Да вообще хотелось бы узнать, а зачем, собсно, UINT8_MAX использовать в preprocessor conditionals? Чего он там забыл то? (ну кроме простейшего ifdef, который от мат операций не зависит)

То есть ни ты, ни тот дрочащий на мамонтовые фекалии обезьян

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

Для сведения: чувак, на статью которого была ссылка — это разраб musl. Но вы-то в сишечке разбираетесь лучше тут.

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

Для gcc’ишного cpp это совершенно валидное выражение.

Да-да, (uint8_t)0 для препроцессора это совершенно валидное целое выражение.

Щя проверим.

vadim@aquila:~$ cat 1.c 
#include <stdio.h>

#define X ((int)10)

int main(void)
{
#if X < 10
	printf("X < 10\n");
#endif
#if X == 10
	printf("X == 10\n");
#endif
#if X > 10
	printf("X > 10\n");
#endif
return 0;
}
vadim@aquila:~$ gcc 1.c
1.c: В функции «main»:
1.c:3:17: ошибка: missing binary operator before token «10»
    3 | #define X ((int)10)
      |                 ^~
1.c:7:5: замечание: в расширении макроса «X»
    7 | #if X < 10
      |     ^
1.c:3:17: ошибка: missing binary operator before token «10»
    3 | #define X ((int)10)
      |                 ^~
1.c:10:5: замечание: в расширении макроса «X»
   10 | #if X == 10
      |     ^
1.c:3:17: ошибка: missing binary operator before token «10»
    3 | #define X ((int)10)
      |                 ^~
1.c:13:5: замечание: в расширении макроса «X»
   13 | #if X > 10
      |     ^
Status: 1
vadim@aquila:~$ 

А над чем ты, собственно, рыдаешь-то?

Сначала над перцами из GCC, теперь над тобой.

Для gcc’ишного cpp это совершенно валидное выражение.

А ЕСЛИ НАЙДУ??????!!!!!!!АДЫНАДЫНАДЫН

$ cat uint_cpp.c
#include <stdio.h>
#include <stdint.h>

#define FOO (~(uint8_t)0)

#if FOO > 255
#define BAR 1
#else
#define BAR 2
#endif

int main() { printf("%d\n", BAR); }
$ gcc uint_cpp.c
uint_cpp.c:4:24: error: missing binary operator before token ‘0’
    4 | #define FOO (~(uint8_t)0)
      |                        ^
uint_cpp.c:6:5: note: in expansion of macro ‘FOO’
    6 | #if FOO > 255
      |   

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

Сишнег – это приговор, это диагноз.

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

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

Вообще, сишники – это единственные программисты на моей памяти, которые активно воюют с компилятором. Для среднего хачкеллиста компилятор – друг и брат, у которого всегда можно запросить инфу о коде. Сишники же ненавидят компиляторы Си. Вся суть программирования на Си для них в том, чтобы на5?(ть компилятор и заставить его компилировать полный грязных хаков и UB говнокод в подобие работающего бинарника. Крайне странная ситуация.

Да вообще хотелось бы узнать, а зачем, собсно, UINT8_MAX использовать в preprocessor conditionals?

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

#if LONG_MAX == INT64_MAX
...
#endif

Это один из немногих способов узнать размер типа в Си на уровне препроцессора. Второй – использовать грязные говнохаки типа множественных вызовов компилятора и ловли ошибок.

Почему мы не любим сишечку и называем её дерьмовеньким говноязычком? Да вот за это вот всё.

А ЕСЛИ НАЙДУ??????

Давай:

$ cat uint_cpp.c 
#include <stdio.h>
#include <stdint.h>
 
#define FOO ((uint8_t)+0)
 
#if FOO > 255
#define BAR 1
#else
#define BAR 2
#endif
 
int main() { printf("%d\n", BAR); }
$ gcc -ansi uint_cpp.c -o uint
$ ./uint 
2

Жду с нетерпением.

#define FOO ((uint8_t)+0)

Дядя, ты совсем бобо? В оригинале было (~(uint8_t)0). Конечно, если ты исправишь невалидный код на валидный, он будет компилироваться. Кто бы мог подумать-то?

а зачем, собсно, UINT8_MAX использовать в preprocessor conditionals?

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

Я как раз вспоминал firkax, читая этот тред)

Кастануть его сюда что ли… Или лучше не будить лихо. (:

Мне тут сейчас вспомнилась фраза из одного очерка по языкам программирования. Уже не помню, какой именно ЯП там обсуждал автор в тот месте, но фразу выдал типа такой: «абстрагироваться от деталей реализации тут возможно, а вот конкретизироваться к ним — нельзя». Вообще хорошая фраза, многие явления через такой ракурс можно рассматривать. Насколько инструмент хорош как в абстракциях, так и в конкретизациях.

И если глобально, то проблема Си очень хорошо описывается этой фразой.

Потому что стандарт языка нам весьма подробно рассказывает о том, чем среда исполнения НЕ ЯВЛЯЕТСЯ, и на что именно полагаться НЕЛЬЗЯ.

А вот как узнать, чем именно она ЯВЛЯЕТСЯ, и на что в ней МОЖНО РАССЧИТЫВАТЬ – на эту тему язык даёт весьма бедные средства, или не даёт вообще.

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

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

При чём в его кривом примере с «исправлением» препроцессор просто считает uint8_t за ноль, так как такого символа не определено.

Это в разделе 6.10.1 прописано. «all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0».

Получилась отличная иллюстрация к «на5?(ть компилятор и заставить его компилировать полный грязных хаков и UB говнокод в подобие работающего бинарника»

А что в процессе этих хаков UINT8_MAX превратилось в ноль, да кого это волнует

Дядя, ты совсем бобо?

Я подозревал, что ты дурачок, но не думал, что вот прям настолько.

В оригинале было

Нет, нет, подожди. В оригинале было:

preprocessor conditionals

В оригинале не было ни одной запятой про то, что это невалидное выражение даёт ошибку компиляции.

При чём в его кривом примере с «исправлением» препроцессор просто считает uint8_t за ноль,

$ cat uint_cpp.c 
#include <stdio.h>
#include <stdint.h>
 
#define FOO (~(uint8_t)+0)
 
#if FOO > 255
#define BAR " > 255"
#elif FOO == 0
#define BAR "geekless прав"
#else
#define BAR "geekless лох"
#endif
 
int main(void)
{
    unsigned char c = FOO;
    unsigned int i = c;
    printf("%u\n", i);
    printf("CPP BAR = %s\n", BAR);
    return 0;
}
 
$ gcc -ansi uint_cpp.c -o uint
$ ./uint 
$ Directed by Robert B. Weide

#define FOO ((uint8_t)+0)

#define FOO (~(uint8_t)+0)

Как же мощно ты сосёшь.

Это ты типа к опечатке докопался?

Так в примере, про который я отвечал, что там ноль, там всё таки ноль или не ноль?

Виляние жопой в зачёт не идёт.

препроцессор просто считает uint8_t за ноль, так как такого символа не определено

Вот в этом ты прав, да.