И ты, Брут...

Этот ваш переносимый sh абсолютно неудобоподдерживаемый

Этот ваш переносимый sh абсолютно неудобоподдерживаемый

УМВР.

1. сам по себе configure править не выйдет, он нечеловекочитаем

2. исходники, из которых собивается configure, тоже так себе в плане удобопонимаемости.

autotools требет знать кучу разных синтаксисов сразу, чтобы написать простейший проект.

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

autotools требет знать кучу разных синтаксисов сразу, чтобы написать простейший проект.

Выросло поколение, которое не знает sh и m4?

Постыдись своего невежества, парень.

Раньше программисты ПИСАЛИ оболочки на завтрак, а нынче скрипты для них прочитать не в состоянии. Тут нечем гордиться.

Взять Си, чтобы написать Питон, чтобы написать на нём DSL, чтобы сгенерировать набор правил для другого DSL, чтобы собирать библиотеку и бинарник на Си, которые в несколько десятков раз меньше всего перечисленного. Победа!

sh убог как язык программирования. m4 тоже так себе в плане удобства

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

Раньше программисты ПИСАЛИ оболочки на завтрак

только они их писали не на завтрак, а годами. Иногда получалось очень годно, тут не поспоришь - но это «годно» достигалось именно что годами

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

и в оптимистичном случае, он сделает это вообще с 0 знаний по теме, все знания которые ему нужны лежат в README.md на гитхабе, который читается за минуту

переносимый

УМВР

ну ты понял

только они их писали не на завтрак, а годами. Иногда получалось очень годно, тут не поспоришь - но это «годно» достигалось именно что годами

Thompson Shell, Bourne Shell, Korn Shell, Almquist Shell, Bill Joy’s C Shell, Tom Duff’s rc, etc.

На годы создания посмотри.

По современным меркам получалось не очень? Так у них не было под рукой монитора на 24 дюйма, процессора на 3 ГГц и IDE, которая умеет варить кофе.

В лучшем случае был vi (даже не vim), а то и вообще ed. И компилятор, который не далеко ушел от ассемблерного макропроцессора.

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

сам по себе configure править не выйдет, он нечеловекочитаем

configure никогда править не нужно, как и любые другие генерируемые файлы

А у некоторых и того не получается, они могут только в тьюринг-неполный DSL.

Кстати да. Автор мезона преподносит тьюринг-неполноту как достоинство (мол, ненаговнокодишь), но из моего сугубо личного опыта – это огроменный минус. Впрочем, такая «тьюринг-полнота» как например в makefile – тоже нафиг не нужна: очередной специфический синтаксис с очень ограниченными возможностями. А вот если взять например java/scala, то sbt по удобству и гибкости на три головы круче того же maven как раз в силу того что билд-скрипт – полноценная программа на скале, которая сама по себе – супер-мощный и супер-выразительный язык. Один и тот же язык и в проекте, и в билд-скрипте – идеально.

java/scala, то sbt

Если брать java/scala для билд-скриптов, то вместо sbt будет cbt.

Gradle с Groovy и Kotlin тоже интересен для Java/Scala/Kotlin.

Ну и зачем такой хлам, который даже не поправить? Не лучше ли использовать систему сборки, которая работает в 1 стадию, а не в 100500 стадий, 100499 из которых имеют нечеловекочитаемый текст файлов?

Если уж такой фанат sh, то почему бы просто не писать build.sh?

Никто ж тебе не запрещает править исходники. Именно исходники, а не генерированную портянку. Стадии не просто так придуманы, собирает в итоге Make

Ну и зачем такой хлам, который даже не поправить? Не лучше ли использовать систему сборки, которая работает в 1 стадию, а не в 100500 стадий, 100499 из которых имеют нечеловекочитаемый текст файлов?

Нет, не лучше.

Система сборки – это make, ninja, tup, etc.

А ./configure – система конфигурирования.

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

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

Ну так почему нельзя сделать человекочитаемый configure?

Выросло поколение, которое не знает sh и m4?

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

А зачем его делать человекочитаемым? Человекочитаемыми должны быть только исходники, откуда configure генерируется, автогенерируемые тексты программ никому не обязаны быть человекочитаемыми. Это один из принципов юникс-вея

Чтобы не было скриптов, которые генерируют скрипты, которые генерируют скрипты.

Ну так почему нельзя сделать человекочитаемый configure?

Может еще человекочитаемый ELF сделать?

Скриптовик не слышал про компиляцию.

Автор мезона преподносит тьюринг-неполноту как достоинство (мол, ненаговнокодишь), но из моего сугубо личного опыта – это огроменный минус.

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

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

Представь, что ./configure это бинарник, и относись к нему соответствующим образом

Чтобы не было скриптов, которые генерируют скрипты, которые генерируют скрипты.

meson генерирует скрипты ninja. Что же делать? Срочно выкини meson!

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

Это именно достоинство, потому что тьюринг-полнота ломает инкрементальную сборку.

У меня на sbt ничего она не ломала. Подробностей сейчас уже не вспомню, но может просто руки были прямые?

Человекочитаемыми должны быть только исходники, откуда configure генерируется

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

«куча всего» нужна только разработчикам, конпелирующим пользователям нужны только sh, make и компилятор

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

Ну так тьюринг-полнота должна быть на этапе конфигурирования, а не сборки.

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

Тот же meson в качестве костылей предлагает вызывать sh-скрипты, если вам нужна, например, поддержка wildcards. Православно-то как!

Загребём все sh-скрипты под капот, а сверху обмажем питоном и облепим красивыми картинами на главной странице гитхаба. С этими модными счётчиками CI-отчётов, лайков и бог знает чего, you know. Красота!

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

Заявления вида «configure + m4 это система конфигурации, а make это система сборки» - бред. Я могу посмотреть, что там configure наконфигурировал? Нет, нормально это не посмотреть. В отличии от той же связки Kconfig + make, где Kconfig выдает абсолютно читаемый .config, который просто подгружается make, без всякого генерирования makefile с помощью m4

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

«Куча всего» состоит из perl и m4 на ОДНОЙ машине – того человека, который готовит релиз сорцов.

А не на КАЖДОЙ машине, где эти сорцы будут собирать.

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

Ну так тьюринг-полнота должна быть на этапе конфигурирования, а не сборки.

Meson умеет переконфигурировать при добавлении новых исходных файлов без сброса инкрементальной сборки. Причём делает это автоматом. make даже распознать изменения Makefile не может.

а не просто скачивать готовый бинарь

И ты тут же предлагаешь скачивать готовый configure

Я могу посмотреть, что там configure наконфигурировал? Нет, нормально это не посмотреть.

Конечно можешь, он пишет это в stdout, когда ты его запустишь. А ещё более подробно в config.log

Я не спроста сказал «нормально». stdout не содержит всего, а парсить config.log это так себе удовольствие

Как легко посмотреть, какие переменные будут подставляться в Makefile?

Я могу посмотреть, что там configure наконфигурировал? Нет, нормально это не посмотреть.

Так сойдёт?

$ cat config.h
/* config.h.  Generated from config.h.in by configure.  */
/* config.h.in.  Generated from configure.ac by autoheader.  */

/* Disable menu related routines */
/* #undef DISABLE_MENU */

/* Disable plugin loading */
/* #undef DISABLE_PLUGINS_LOADING */

/* Define to 1 if translation of program messages to the user's native
   language is requested. */
#define ENABLE_NLS 1

/* Define to the gettext package name. */
#define GETTEXT_PACKAGE "waterline"

/* Define to 1 if you have the <alsa/asoundlib.h> header file. */
#define HAVE_ALSA_ASOUNDLIB_H 1

/* Define to 1 if you have the `bzero' function. */
#define HAVE_BZERO 1

/* Define to 1 if you have the MacOS X function CFLocaleCopyCurrent in the
   CoreFoundation framework. */
/* #undef HAVE_CFLOCALECOPYCURRENT */

/* Define to 1 if you have the MacOS X function CFPreferencesCopyAppValue in
   the CoreFoundation framework. */
/* #undef HAVE_CFPREFERENCESCOPYAPPVALUE */

/* Define if the GNU dcgettext() function is already present or preinstalled.
   */
#define HAVE_DCGETTEXT 1

/* Define to 1 if you have the declaration of `strmode', and to 0 if you
   don't. */
#define HAVE_DECL_STRMODE 0

/* Define to 1 if you have the <dlfcn.h> header file. */
#define HAVE_DLFCN_H 1

/* Define if the GNU gettext() function is already present or preinstalled. */
#define HAVE_GETTEXT 1

/* Define if you have the iconv() function and it works. */
/* #undef HAVE_ICONV */

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1

/* Define to 1 if you have the <linux/soundcard.h> header file. */
#define HAVE_LINUX_SOUNDCARD_H 1

/* Define to 1 if you have the <locale.h> header file. */
#define HAVE_LOCALE_H 1

/* Define to 1 if your system has a GNU libc compatible `malloc' function, and
   to 0 otherwise. */
#define HAVE_MALLOC 1

/* Define to 1 if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1

/* Define to 1 if you have the `memset' function. */
#define HAVE_MEMSET 1

/* Define to 1 if you have the `mkdir' function. */
#define HAVE_MKDIR 1

/* Define to 1 if you have the `setlocale' function. */
#define HAVE_SETLOCALE 1

/* Define to 1 if `stat' has the bug that it succeeds when given the
   zero-length file name argument. */
/* #undef HAVE_STAT_EMPTY_STRING_BUG */

/* Define to 1 if you have the <stdint.h> header file. */
#define HAVE_STDINT_H 1

/* Define to 1 if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1

/* Define to 1 if you have the `strchr' function. */
#define HAVE_STRCHR 1

/* Define to 1 if you have the `strftime' function. */
#define HAVE_STRFTIME 1

/* Define to 1 if you have the <strings.h> header file. */
#define HAVE_STRINGS_H 1

/* Define to 1 if you have the <string.h> header file. */
#define HAVE_STRING_H 1

/* Define to 1 if you have the <sys/soundcard.h> header file. */
#define HAVE_SYS_SOUNDCARD_H 1

/* Define to 1 if you have the <sys/stat.h> header file. */
#define HAVE_SYS_STAT_H 1

/* Define to 1 if you have the <sys/sysinfo.h> header file. */
#define HAVE_SYS_SYSINFO_H 1

/* Define to 1 if you have the <sys/time.h> header file. */
#define HAVE_SYS_TIME_H 1

/* Define to 1 if you have the <sys/types.h> header file. */
#define HAVE_SYS_TYPES_H 1

/* Define to 1 if you have <sys/wait.h> that is POSIX.1 compatible. */
#define HAVE_SYS_WAIT_H 1

/* Define to 1 if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1

/* Define to 1 if `lstat' dereferences a symlink specified with a trailing
   slash. */
#define LSTAT_FOLLOWS_SLASHED_SYMLINK 1

/* Define to the sub-directory where libtool stores uninstalled libraries. */
#define LT_OBJDIR ".libs/"

/* - */
#define MENU_CACHE_MAJOR_VERSION 1

/* - */
#define MENU_CACHE_MICRO_VERSION 0

/* - */
#define MENU_CACHE_MINOR_VERSION 1

/* Name of package */
#define PACKAGE "waterline"

/* Define to the address where bug reports for this package should be sent. */
#define PACKAGE_BUGREPORT "https://github.com/sde-gui/waterline"

/* Define to the full name of this package. */
#define PACKAGE_NAME "waterline"

/* Define to the full name and version of this package. */
#define PACKAGE_STRING "waterline 0.6.0-alpha"

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME "waterline"

/* Define to the home page for this package. */
#define PACKAGE_URL ""

/* Define to the version of this package. */
#define PACKAGE_VERSION "0.6.0-alpha"

/* Define as the return type of signal handlers (`int' or `void'). */
#define RETSIGTYPE void

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

/* Define to 1 if your <sys/time.h> declares `struct tm'. */
/* #undef TM_IN_SYS_TIME */

/* Version number of package */
#define VERSION "0.6.0-alpha"

/* Define to empty if `const' does not conform to ANSI C. */
/* #undef const */

/* Define to `__inline__' or `__inline' if that's what the C compiler
   calls it, or to nothing if 'inline' is not supported under any name.  */
#ifndef __cplusplus
/* #undef inline */
#endif

/* Define to rpl_malloc if the replacement function should be used. */
/* #undef malloc */

Я могу посмотреть, что там configure наконфигурировал? Нет, нормально это не посмотреть. В отличии от той же связки Kconfig + make, где Kconfig выдает абсолютно читаемый .config, который просто подгружается make, без всякого генерирования makefile с помощью m4

А в чём принципиальная разница? configure делает тебе Makefile из шаблона (в принципе, это может быть что угодно, не обязательно Makefile). А твой читаемый .config всё равно должен соответствовать синтаксису Make-а

«куча всего» нужна только разработчикам, конпелирующим пользователям нужны только sh, make и компилятор

Править кривые configure нужно почти всегда, а делать это с генерёнными файлами адовый ад. Да и собирают часто из реп, куда генеренные файлы не кладут. Так что не надо врать про make и sh, в общем случае всегда нужен полный комплект автокрапа.

Править кривые configure нужно почти всегда,

Ты что-то делаешь не так. Назови хоть один повод, сходу

.config имеет формат

CONFIG_TOOLCHAIN_PREFIX=""
CONFIG_COMPILE_OPTIMIZATION_NONE=y
# CONFIG_COMPILE_OPTIMIZATION_FOR_SIZE is not set
CONFIG_COMPILE_STACK_PROTECTION_NONE=y
# CONFIG_COMPILE_STACK_PROTECTION_ALL is not set
CONFIG_COMPILE_DEBUG=y
# end of Compilation

# CONFIG_PLATFORM_MEGA2560 is not set
# CONFIG_PLATFORM_STM32F103 is not set
CONFIG_PLATFORM_EMULATION=y

что полностью человекочитаемо

Это то, что идет в C файлы (кстати, а что если проект не на C/C++?). А где то, что идет в Makefile?

Ты что-то делаешь не так. Назови хоть один повод, сходу

Запросто - когда вышла FreeBSD 10 то под неё перестало собираться чуть более чем всё и правку configure пришлось делать централизованно потому что там повсеместно было понапихано что-то типа freebsd[0-9]. А так-то достаточно посмотреть на патчи для configure и Makefile, их огромное количество.

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

Секция Output variables в config.log. Либо, то же самое, – набор строк вида S["key"]="value" в config.status.

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

Да что вы говорите, как же мы не догадались. Конечно это первым делом пофиксили в autocrap. Только ничего что все кривые configure в мире от этого магически не перегенерятся? Поэтому без autoreconf к configure подходить бесполезно, хренов вам в панаму, а не «sh и make». Но мегабайт нечитабельного неработающего говна с каждым дистрибутивом качаем, да.

А можно я не буду парсить config.log?

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

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

конпелирующим пользователям нужны только sh, make и компилятор

Угу, особенно когда configure сыпется с адовыми ошибками, что не найдены либы из хомяка

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

Как там в параллельной реальности: поиск в текстовый редактор еще не завезли?

Угу, особенно когда configure сыпется с адовыми ошибками, что не найдены либы из хомяка

А meson их находит сам. Шебуршит лапками по всему диску и находит.

Сказки не рассказывай, ага?

Поиск по портянке - это время и силы. Система сборки должна максимально помогать человеку, а не «ну ты, если покопаешься, может быть поймешь, в чем тут дело»

Я про autotools... Сорри.

autotools не может найти либы из хомяка? Понятнее не стало. Сорри.

Сам придумал себе проблему, сам жалуется.

«куча всего» нужна только разработчикам, конпелирующим пользователям нужны только sh, make и компилятор

Генерируемые файлы не должны быть в составе проекта. Если configure генерируемый, то он должен быть в .gitignore и в инструкции по сборке должно быть написано как его генерировать. А лучше просто взять cmake/meson и забыть про всё это как страшный сон.

Если configure генерируемый, то он должен быть в .gitignore и в инструкции по сборке должно быть написано как его генерировать.

да

а если мы делаем тарболл с релизом, то configure генерируется и туда кладётся

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

Kconfig делает простой и понятный конфигурационный файл.

Если configure генерируемый, то он должен быть в .gitignore

Он и так в .gitignore. Открытие за открытием…

А лучше просто взять cmake/meson и забыть про всё это как страшный сон.

Спасибо, но я уже перевёл свои проекты обратно на autotools и забыл бесполезный кусок говнокода cmake как страшный сон.

Сделать DSL после которого даже sh кажется раем – это надо было постараться.

то configure генерируется и туда кладётся

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

Он и так в .gitignore. Открытие за открытием…

тогда в склонированном проекте его не будет

Раньше как бывало - configure собран под тулчейн разработчика, у юзера не работает, нужно пересобирать, искать ту же версию autotools...

тогда в склонированном проекте его не будет

Не будет.

Лапками ставишь automake и autoconf и вперёд.

Слишком сложная концепция, что для сборки релизнутого софта и для его разработки требуется разный набор инструментов? А еще для сборки не нужен git и IDE. Прикинь?

он кроссплатформенный по замыслу

Лапками ставишь automake и autoconf и вперёд.

…правильной версии (и не обязательно самой новой) и с кастомными патчами.

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

– Как не придётся? Вывсёврёти!

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

он кроссплатформенный по замыслу

Но практика почему-то замыслу не всегда соответствует.

Про твою фантазию я уже знаю из других топиков, можешь не продолжать. То софт с TUI устарел, то на automake патчи нужны кастомные.

Нормальный опенсорс софт распространяется через git или иную систему контроля версий, а не всякие тарболлы

CMakeLists.txt конечно же никогда править не нужно, сразу под любую платформу конпеляет сходу и без ошибок

CMakeLists.txt человекочитаемый, а не сгенерированный. Поэтому править его не проблема

CMakeLists.txt конечно же никогда править не нужно

Править нужно исходники, а не генерируемые файлы.

для сборки релизнутого софта и для его разработки требуется разный набор инструментов?

Вообще то нет. Софт на компьютере разработчика и не-разработчика должен собираться одинаковым образом. Хотя бы чтобы избежать ситуации «Пользователь: есть проблема такая-то, разработчик: умвр»

configure.ac человекочитаемый, а не сгенерированный. Поэтому править его не проблема

configure.ac человекочитаемый, а не сгенерированный.

Ну вот пусть он и будет. А сгенерированные файлы в исходниках релизов не нужны.

Это и есть исходник

Тогда зачем тянуть еще и configure, если есть configure.ac?

Но практика почему-то замыслу не всегда соответствует.

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

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

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

NIH-синдром жесток.

Как в вашем любимом cmake был свой отдельный набор костылей под каждую библиотеку и платформу или их комбинацию

Ты о pkg-config чтоли?

шоб время тебе сэкономить

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

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

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

cmake, meson и многие другие системы сборки поддерживают pkgconfig.

Как в вашем любимом cmake был свой отдельный набор костылей под каждую библиотеку и платформу или их комбинацию, с эвристикой на эвристике – оч надёжно.

Можно обходиться и без них.

шоб время тебе сэкономить

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

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

Ну так это конкретно автотулзы сложные и есть)

остальные ещё сложнее

Остальные хотя бы без проблем распространяются в виде чисто исходных конфигурационных файлов, не требующих «для экономии времени» дополнительно прикладывать сгенерированные файлы

Ну и шаблоны m4 это жопа в плане синтаксиса.

остальные ещё сложнее

Очень сложно.

CMakeLists.txt человекочитаемый, а не сгенерированный.

Сходу этого и не скажешь.

правильно давать ссылку сюда

https://mesonbuild.com/Reference-manual.html

Странно, но в причине треда сборка под сложный meson занимает 500 строк, а при удалении сборки под простой autotools удалили 1800 строк.

Можно обходиться и без них.

А можно и не обходиться.

These modules search for third-party software. They are normally called through the find_package() command.

    FindALSA
    FindArmadillo
    FindASPELL
    FindAVIFile
    FindBISON
    FindBLAS
    FindBacktrace
    FindBoost
    FindBullet
    FindBZip2
    FindCABLE
    FindCoin3D
    FindCups
    FindCUDAToolkit
    FindCURL
    FindCurses
    FindCVS
    FindCxxTest
    FindCygwin
    FindDart
    FindDCMTK
    FindDevIL
    FindDoxygen
    FindEnvModules
    FindEXPAT
    FindFLEX
    FindFLTK2
    FindFLTK
    FindFontconfig
    FindFreetype
    FindGCCXML
    FindGDAL
    FindGettext
    FindGIF
    FindGit
    FindGLEW
    FindGLUT
    FindGnuplot
    FindGnuTLS
    FindGSL
    FindGTest
    FindGTK2
    FindGTK
    FindHDF5
    FindHg
    FindHSPELL
    FindHTMLHelp
    FindIce
    FindIcotool
    FindICU
    FindImageMagick
    FindIconv
    FindIntl
    FindITK
    FindJasper
    FindJava
    FindJNI
    FindJPEG
    FindKDE3
    FindKDE4
    FindLAPACK
    FindLATEX
    FindLibArchive
    FindLibinput
    FindLibLZMA
    FindLibXml2
    FindLibXslt
    FindLTTngUST
    FindLua50
    FindLua51
    FindLua
    FindMatlab
    FindMFC
    FindMotif
    FindMPEG2
    FindMPEG
    FindMPI
    FindODBC
    FindOpenACC
    FindOpenAL
    FindOpenCL
    FindOpenGL
    FindOpenMP
    FindOpenSceneGraph
    FindOpenSSL
    FindOpenThreads
    FindosgAnimation
    FindosgDB
    Findosg_functions
    FindosgFX
    FindosgGA
    FindosgIntrospection
    FindosgManipulator
    FindosgParticle
    FindosgPresentation
    FindosgProducer
    FindosgQt
    Findosg
    FindosgShadow
    FindosgSim
    FindosgTerrain
    FindosgText
    FindosgUtil
    FindosgViewer
    FindosgVolume
    FindosgWidget
    FindPatch
    FindPerlLibs
    FindPerl
    FindPHP4
    FindPhysFS
    FindPike
    FindPkgConfig
    FindPNG
    FindPostgreSQL
    FindProducer
    FindProtobuf
    FindPython
    FindPython2
    FindPython3
    FindQt3
    FindQt4
    FindQuickTime
    FindRTI
    FindRuby
    FindSDL_image
    FindSDL_mixer
    FindSDL_net
    FindSDL
    FindSDL_sound
    FindSDL_ttf
    FindSelfPackers
    FindSquish
    FindSQLite3
    FindSubversion
    FindSWIG
    FindTCL
    FindTclsh
    FindTclStub
    FindThreads
    FindTIFF
    FindUnixCommands
    FindVTK
    FindVulkan
    FindWget
    FindWish
    FindwxWidgets
    FindXCTest
    FindXalanC
    FindXercesC
    FindX11
    FindXMLRPC
    FindZLIB

Я тут открыл ради интереса пару файлов. А читабельно-то как! Куда там этому замшелому sh. Тут подошли к делу обфускации кода творчески:

  foreach (implementation IN LISTS _PGF_IMPLEMENTATIONS)
    if (implementation STREQUAL "CPython")
      foreach (version IN LISTS _PGF_VERSION)
        foreach (framework IN LISTS _${_PYTHON_PREFIX}_${implementation}_FRAMEWORKS)
          if (EXISTS "${framework}/Versions/${version}")
            list (APPEND framework_paths "${framework}/Versions/${version}")
          endif()
        endforeach()
      endforeach()
    elseif (implementation STREQUAL "IronPython")
      foreach (version IN LISTS _PGF_VERSION)
        foreach (framework IN LISTS _${_PYTHON_PREFIX}_${implementation}_FRAMEWORKS)
          # pick-up all available versions
          file (GLOB versions LIST_DIRECTORIES true RELATIVE "${framework}/Versions/"
                              "${framework}/Versions/${version}*")
          list (SORT versions ORDER DESCENDING)
          list (TRANSFORM versions PREPEND "${framework}/Versions/")
          list (APPEND framework_paths ${versions})
        endforeach()
      endforeach()
    endif()
  endforeach()

Вот после того как мне пришлось пописать и поотлаживать такой код в течение неск. месяцев, я и перевел сборку на autotools. Там по крайней мере при чтении не кровоточат глаза.

он кроссплатформенный по замыслу

Только ни macOS, ни Windows, ни Android, ни iOS не поддерживает. Кросс-платформенность уровня /autotools.

А ну да, зато поддерживает всякие там AIX, IRIX, QNX, SCO Unix, Solaris, HP-UX и прочие мёртвые и вытесненные Linux’ом UNIX’ы.

Очень актуально для 2020, да.

Только ни macOS, ни Windows, ни Android, ни iOS не поддерживает. Кросс-платформенность уровня /autotools.

У меня поддерживает

что, прям собранный под linux configure без проблем запускается везде? И даже не требуется пол-линукса затащить в целевую ОС?

Как мне под виндой запустить configure? Без установки всяких msys2 и прочего?

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

Ммм… это самый смак CMake-обосрамса – Оценки хелловорлда тред (комментарий)

Давай пруф в виде GitHub-репозитория.

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

Ходячие мертвецы из зомби-фильмов тоже шевелятся

Вот да, спасибо за ссылку! Я давно не имею дела с этим адом, так что в красках описать бы не вышло.

никому эти find модули не нужны, есть pkg-config, которым и пользуются нормальные люди

These modules search for third-party software. They are normally called through the find_package() command.

Видимо это по большей части для авторов криворуких дистрибутивостроителей. При порте на новые платформы, например на Haiku, иногда приходится часть этого выпиливать и руками прописывать пути или переделывать на pkgconfig.

что, прям собранный под linux configure без проблем запускается везде? И даже не требуется пол-линукса затащить в целевую ОС?

Как мне под виндой запустить configure? Без установки всяких msys2 и прочего?

Я дико извиняюсь, но в линуксе сборочный софт тоже нужно затащить, он не идёт из коробки везде в любом дистре

Соляра недавно обновление выкатила

Вот по этому JEP видно как Oracle собирается Solaris в будущем поддерживать :^)

https://openjdk.java.net/jeps/381

В винде надо не просто сборочный софт затащить, надо поллинукса на винду затащить

Как мне под виндой запустить configure? Без установки всяких msys2 и прочего?

А как запустить CMakeLists.txt без установки CMake?

никому эти find модули не нужны, есть pkg-config, которым и пользуются нормальные люди

И который, внезапно, только Linux-only.

cmake это отдельная утилитка. msys2 - огромный комбайн, тащящий поллинукса на винду

Можно из линукса под винду кросскомпилировать. Автотулзы этому очень способствуют. И собирается быстрее

тащящий поллинукса на винду

в состав msys2 не входит ни ядро Linux, ни его половина

И который, внезапно, только Linux-only.

Что в нём Linux-only? Там просто пути и аргументы для компилятора.

правильно давать ссылку сюда

Исходники готового проекта с инструкцией по сборке нагляднее. А для деталей можно смотреть документацию.

И который, внезапно, только Linux-only.

нет, он вполне себе кроссплатформенный

то, что ты приводишь как пример - это эквивалент ./configure && make install

а размеры Visual Studio и время установки тебя не смущают?

Кроссплатформенность такая кроссплатформенность….

Зато входит половина окружения gnu/linux

то, что ты приводишь как пример - это эквивалент ./configure && make install

Предлагаю ещё посмотреть исходники объявлений сборки и сравнить.

А в винде компиляция не требует visual studio, достаточно поставить компилятор, он отдельно идет

Что в нём Linux-only? Там просто пути и аргументы для компилятора.

Под cl.exe?

Давай пруф в виде GitHub-репозитория.

https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L575

нет, он вполне себе кроссплатформенный

Ну да, примерно такой же «кроссплатформенный», как и autotools.

кто ж виноват, что винда такая убогая

А если у меня не mingw, а обычная винда с cl.exe?

Ктож виноват, что autotools не умеют в кроссплатформенность

проприетарщина не нужна, есть же mingw-w64

а всякие проприетарные hpux и прочее - нужно?

mingw

Так а что там с iOS?

есть же mingw-w64

в mingw-w64 уже умеют собирать нативно под винду, чтобы не требовалось тащить mingw бибилиотеки с собой?

А если у меня не mingw, а обычная винда с cl.exe?

тогда тебе придётся ручками немного подшаманить над configure.ac и Makefile.am, чтобы они учитывали все особенности cl.exe

всегда умело

так ведь в винду точно умеет, пруфы есть :)

для начала, даже если ты каким то чудом сделаешь из configure.ac configure, то ты даже его запустить не сможешь, т.к. без sh его не запустить

а если ты не установишь cl.exe, то ты не сможешь скомпилировать

cl.exe не тянет за собой половину другой операционной системы

то не операционная система, то набор свободного софта

который чисто случайно совпадает с половиной другой операционной системы

if test x$WINDRES = xnone; then

Ммм, мои любимые костыли из 70-х.

Предлагаю ещё посмотреть исходники объявлений сборки и сравнить.

Здравствуйте, это конкурс хелло ворлдов?

$ grep . configure.ac Makefile.am hello.c 
configure.ac:AC_PREREQ([2.63])
configure.ac:AC_INIT([hello], [0.0.1])
configure.ac:AC_CONFIG_AUX_DIR([build-aux])
configure.ac:AM_INIT_AUTOMAKE([-Wall -Werror foreign])
configure.ac:AC_PROG_CC
configure.ac:AM_PROG_CC_C_O
configure.ac:AC_CONFIG_FILES([
configure.ac:    Makefile
configure.ac:])
configure.ac:AC_OUTPUT
Makefile.am:bin_PROGRAMS = hello
Makefile.am:hello_SOURCES = hello.c
hello.c:#include <stdio.h>
hello.c:int main(void)
hello.c:{
hello.c:    printf("Hello, World!\n");
hello.c:    return 0;
hello.c:}

Так а что там с iOS?

Если порассуждать, что под iOS обычно пишут под macOS, а там автотулзы без проблем запускаются и работают, то можно придти к очевидному выводу, что принципиальных проблем со сборкой автотулзами для iOS не будет

Linux-only

Под cl.exe?

Какая связь?

Да, умеют. Но там извечные проблемы с выбором модели исключений и порты новых компиляторов (а это новые стандарты) не слишком быстро выходят. В любом случае MinGW и MinGW-w64 и MSYS2 в Windows инородны.

в mingw-w64 уже умеют собирать нативно под винду, чтобы не требовалось тащить mingw бибилиотеки с собой?

ты случаем не путаешь с Cygwin и зависимостью от cygwin.dll?

С другой стороны cl.exe тянет ~10 GB студии.

https://docs.microsoft.com/ru-ru/cpp/build/building-on-the-command-line?view=vs-2019

А в винде компиляция не требует visual studio, достаточно поставить компилятор, он отдельно идет

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

И ты, Брут... (комментарий)

ну значит, у мелкософта проблеск разума случился

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

Ну правильнее было бы сказать Unix-only. Но поскольку из Unix-like сегодня актуальны лишь Linux, macOS, Android и iOS для которых pkg-config инороден как и для Windows, то сфера его применения довольно ограничена. Примерно так же, как autotools для Windows. И в Windows и в macOS для работы pkg-config и autotools требуются «подсистемы» вроде MSYS2, Cygwin, Homebrew и т. д.

Вообще, это конечно большой промах со стороны авторов pkg-config, что они выбрали такой формат файлов, который зависим от Linux.

     AC_CHECK_LIB([user32],   [main],, AC_MSG_ERROR(libuser32 missing))
     AC_CHECK_LIB([gdi32],    [main],, AC_MSG_ERROR(libgdi32 missing))
     AC_CHECK_LIB([comdlg32], [main],, AC_MSG_ERROR(libcomdlg32 missing))
     AC_CHECK_LIB([winmm],    [main],, AC_MSG_ERROR(libwinmm missing))
     AC_CHECK_LIB([shell32],  [SHGetSpecialFolderPathW],, AC_MSG_ERROR(libshell32 missing))
     AC_CHECK_LIB([comctl32], [main],, AC_MSG_ERROR(libcomctl32 missing))
     AC_CHECK_LIB([ole32],    [CoCreateInstance],, AC_MSG_ERROR(libole32 missing))
     AC_CHECK_LIB([oleaut32], [main],, AC_MSG_ERROR(liboleaut32 missing))
     AC_CHECK_LIB([uuid],     [main],, AC_MSG_ERROR(libuuid missing))
     AC_CHECK_LIB([advapi32], [CryptAcquireContextW],, AC_MSG_ERROR(libadvapi32 missing))
     AC_CHECK_LIB([ws2_32],   [WSAStartup],, AC_MSG_ERROR(libws2_32 missing))
     AC_CHECK_LIB([shlwapi],  [PathRemoveFileSpecW],, AC_MSG_ERROR(libshlwapi missing))
     AC_CHECK_LIB([iphlpapi], [GetAdaptersAddresses],, AC_MSG_ERROR(libiphlpapi missing))

И вот что реально есть экземпляры Windows без этих библиотек?

Спасибо за информацию, раньше был прямо EXE-файл на MSDN, скачав который ты получал компилятор, MASM и пр. command-line tools. Потом его убрали, думал совсем. Оказывается в опцию инсталлятора Visual Studio включили.

Не слишком-то очевидно, ИМХО.

Зато эти «подсистемы» дают тебе готовый репозиторий с пакетами, с «нативным» подходом тебе придётся пердолиться с самостоятельной сборкой всех зависимостей, которым наверняка всё равно нужны будут автотулзы

И вот что реально есть экземпляры Windows без этих библиотек?

Там идёт проверка этих библиотек (пустышек для линковки) в инородном для Windows тулчейне MinGW-w64, в котором иногда из версии в версию их «теряют».

какого-то конкретного файлика внезапно может и не быть, это раз, во-вторых, всё равно ищутся *.dll.a файлы (типа файл экспорта для конкретной DLL), в третьих, AC_CHECK_LIB() добавляет указанную библиотеку в команду линковки

Оу, а вот это не здорово. Если для линковки с системными виндовыми библиотеками требуются заглушки в mingw, то что насчет линковки с прочими виндовыми библиотеками, которые в mingw не имеют заглушек?

$ grep -ohr -- ' -.' /usr/lib/pkgconfig/ | sort | uniq -c | sort -n
      1  -O
      1  -r
      2  -e
      2  -R
      5  -m
      5  -s
      6  --
      8  -i
     15  -f
     29  -W
     51  - 
     95  -p
    195  -D
   1178  -L
   1277  -I
   2500  -l

Ты уверен, что здесь есть хоть какая-то практическая проблема в конвертировании этого в опции cl.exe на лету?

Было бы желание. А желания, видимо, не было.

У нативного подхода есть всякие там VCPKG и прочее. Без медленного и форкающегося autotools.

Ты не сможешь слинковаться с проприетарной C++ либой из MinGW-w64, например.

C++ ABI, мать его.

Вот это совсем не круто, что в mingw несовместимый abi

то что насчет линковки с прочими виндовыми библиотеками, которые в mingw не имеют заглушек?

что значит «прочими виндовыми библиотеками»? Либо ты конпеляешь эту библиотеку сам, либо генерируешь из .dll эту заглушку и надеешься, что она будет совместимой, чего в случае C++ ожидать наивно, программа и все её зависимости должны быть скомпилены одним и тем же компилятором для совместимости

Здравствуйте, это конкурс хелло ворлдов?

Зачем 2 файла сборки?

Meson:

> grep . meson.build main.c
meson.build:project('MinApp', 'c',
meson.build:    version : '1.0')
meson.build:executable('MinApp',
meson.build:    'main.c',
meson.build:    install : true)
main.c:#include <stdio.h>
main.c:int main(int argc, const char **argv)
main.c:{
main.c: printf("This is TestApp.\n");
main.c: return 0;
main.c:}

> meson build
The Meson build system
Version: 0.55.0
Source dir: /Haiku 64 (USB)/home/Tests/meson/meson/Test1
Build dir: /Haiku 64 (USB)/home/Tests/meson/meson/Test1/build
Build type: native build
Project name: MinApp
Project version: 1.0
C compiler for the host machine: cc (gcc 8.3.0 "cc (2019_05_24) 8.3.0")
C linker for the host machine: cc ld.bfd 2.26.1
Host machine cpu family: x86
Host machine cpu: bepc
Build targets in project: 1

Found ninja-1.10.0 at /bin/ninja
> ninja -C build
ninja: Entering directory `build'
[2/2] Linking target MinApp
> build/MinApp
This is TestApp.

Если добавить новый исходный файл, то ninja -C build автоматически переконфигурирует проект.

AC_CHECK_LIB() добавляет указанную библиотеку в команду линковки

Интуитивно. Из серии «— А как проверить наличие таблицы в базе? — Командой DROP TABLE. Если успешно, значит таблица была».

у С++ в принципе совместимость ABI нигде не гарантируется

Ну, справедливости ради, надо заметить, что до VS2017 Microsoft на каждую мажорную версию компилятора ломала ABI и только начиная с 2015 (->2017->2019) сохраняется ABI.

Вот за этим и надо пользоваться cl.exe и прочими нативными системами.

Разработчикам gcc и clang это расскажи

для них тоже верно

Вот это совсем не круто, что в mingw несовместимый abi

В clang совместимый. Даже манглинг от Microsoft понимает.

Интуитивно.

Он просто опустил опциональные аргументы.

AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])

If action-if-found is not specified, the default action prepends -llibrary to LIBS and defines ‘HAVE_LIBlibrary’ (in all capitals).

Да, а то они сохраняют для языка ABI с gcc 3.4, а для стандартной библиотеки было изменение ABI для std::string и std::list в 5.0, которое могло отключаться.

Зачем 2 файла сборки?

Затем, что в реальном проекте ты всё равно будешь делить это всё на файлы, чтобы не запутаться.

AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])

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

То есть этот тред ты создал не про реальный проект? И мне мерещится, что там, вместо пары десятков Makefile.am, остался один meson.build? Или, может, не во всех системах сборки можно запутаться с одним файлом?

Затем, что в реальном проекте ты всё равно будешь делить это всё на файлы, чтобы не запутаться.

Как-то пока не запутываюсь. И деление происходит по другому принципу.

Вот это совсем не круто, что в mingw несовместимый abi

Вряд ли его можно сделать MVSC’шным, MinGW же по сути просто порт GCC и использует тот же mangling как и везде, насколько я понимаю.

А ещё из того с чем я сталкивался – мешать либы собранные разными версиями MinGW довольно опасно. Натыкался иногда на рандомные сегфолты (в терминологии Windows – Memory Access Violation).

это всего лишь вызов функции, точнее макроса

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

И мне мерещится, что там, вместо пары десятков Makefile.am

никто ж не запрещал всё в одном Makefile.am держать, просто разработчик в своё время сделал такой выбор

а размеры Visual Studio и время установки тебя не смущают?

В Visual Studio кстати при установке устанавливает не только msbuild, но и cmake, и ninja, а также nmake

Так что их отдельно скачивать и устанавливать не нужно…

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

Ну вот гражданин выше утверждал, что тогда можно запутаться. Да и разработчик же разделил по какой-то причине? А meson.build не стал делить (возможно, по той простой причине, что он в 4 раза меньше, чем были Makefile.am в сумме).

Есть два подхода, либо в каждой поддиректории проекта свой мейкфайл (и соответственно Makefile.am, его порождающий), либо один общий мейкфайл на весь проект. С размерами содержимого это мало связано

сбт это тот, при сборке с которым можно идти курить, да?

Я не понял ты защищаешь или нет? А то готовое по с одной стороны и запускать на одной машине с другой

сбт это тот, при сборке с которым можно идти курить, да?

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

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

Только мавен быстрее все равно. И ещё ряд фич типа парентов, которые на сбт нужно ещё извернуться

Только мавен быстрее все равно. И ещё ряд фич типа парентов, которые на сбт нужно ещё извернуться

Спорить с бредом не имею желания.

а если мы делаем тарболл с релизом, то configure генерируется и туда кладётся

А можно сделать так, чтобы autotools генерировал файлы, включая configure, в директорию сборки, а не исходников? Не хочу видеть эту помойку в директории исходников. cmake/meson/jam так умеют.

Есть команда вычистки всех сгенерированных autotools файлов?

Есть команда вычистки всех сгенерированных autotools файлов?

git clean -dfx ?

Не хочу видеть эту помойку в директории исходников.

AC_CONFIG_AUX_DIR([build-aux])

git clean -dfx

Без git никак? Есть официальный список .gitignore для autotools?

AC_CONFIG_AUX_DIR([build-aux])

Не помогло. Следующие файлы по-прежнему в корне:

aclocal.m4
autom4te.cache
config.h.in
configure
src/makefile.in
autom4te.cache

А можно сделать так, чтобы autotools генерировал файлы, включая configure, в директорию сборки, а не исходников? Не хочу видеть эту помойку в директории исходников. cmake/meson/jam так умеют.

Сборку проекта в отдельной директории конечно же умеет, но configure должен знать путь к исходникам, так что конкретно этот файл нет.

Есть команда вычистки всех сгенерированных autotools файлов?

make distclean

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

И ты, Брут... (комментарий)

make distclean

Файлы, сгенерированные autotools (configure, aclocal.m4, …) оно не удаляет. Оно удаляет только результаты make (бинарники и т.п.).

можешь заглянуть в документацию автоконфа

Где в этой простыне написано, как указать путь куда будут генерироваться configure, aclocal.m4 и т.д.? Засорять корень исходников не предлагать.

$100 в час за чтение документации с выражением :)

В 3.5 Using autoreconf to Update configure Scripts я в упор не вижу ключа, который указывает куда генерировать configure, aclocal.m4, …. Они всегда генерируются в корень исходников. AC_CONFIG_AUX_DIR не помогает.

Не хочу видеть эту помойку в директории исходников. cmake/meson/jam так умеют.

А работать говно cmake умеет? Тут потребовалось собрать старые сорцы. На cmake3 сорцы нормально не собираются. Cmake2 сама не собирается на современной ОС.

The END

Directed by Robert B. Weide.

/////////////////////////////////

Тем временем «эта помойка» работает даже на сорцах, которому по 10-15 лет.

Тут потребовалось собрать старые сорцы. На cmake3 сорцы нормально не собираются. Cmake2 сама не собирается на современной ОС.

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

Тем временем «эта помойка» работает даже на сорцах, которому по 10-15 лет.

Зачем тогда в репозиториях несколько версий autotools и некоторые значимые проекты например Firefox от них зависят?

Это проблема языка C/C++ и системы заголовков.

Нет, это проблема кривой сборки.

несколько версий autotools

И все они работают, заметь. А не лежат как памятник эпохе, не работающий без патчей.

Зачем

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

Ну и чтоб два раза не вставать, поною здесь же на другую тему.

• Библиотека выкидывает хидер не то что без смены major, а даже без смены minor версии.
• В документации не просто нет секции о миграции между версиями, но даже ни разу не грепается слово deprecated.
• В репозитории сорцов всё свалено в одну кучу, так что даже быстро список коммитов, отфильтрованный по каталогу, не посмотреть.

cmake тут при том, что подобное тянется к подобному, по всей видимости.

И все они работают, заметь.

Работники музея тщательно следят за экспонатами. История UNIX как-никак.

А не лежат как памятник эпохе, не работающий без патчей.

Видимо потому что в старых версиях нет необходимости и проблемы при переходе на новую версию редко возникают и их легко починить. В autotools минорное обновление всё так поломало, что больше 10 лет в значимом проекте починить не могут.

Библиотека выкидывает хидер не то что без смены major, а даже без смены minor версии.

Дай угадаю: приватное недокументированное API? Или это GTK4?

Дай угадаю: приватное недокументированное API?

Не угадал. Публичное API. Просто автор творец и так видит.

Просто автор творец и так видит.

Ну и зачем тогда этим пользоваться? Написали говнокод, а виноват cmake?