И ты, Брут...

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

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

И который, внезапно, только 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 его не запустить

В общем, ребята, у нас в C/C++ ‘‘‘‘экосистеме’’’’ расклад такой:

моча > waf, jam, premake, meson, qbs, tup, {вставь сюда свою любимую маргинальщину}, gradle > Pure Makefiles > QMake > говно > CMake > autotools > SCons

Бегите!

а если ты не установишь 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?

Кстати, как я забыл про jam!

С другой стороны 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, мать его.