И ты, Брут...

Вот это совсем не круто, что в 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 инкрементальный резолвер зависимостей, который на скала-проектах реально творит чудеса.

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

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

А кубус разве не утонул? Я все ждал ждал, пока им можно будет пользоваться

Утонул для Qt, но внезапно всплыл у Embedded-разработчиков:

https://habr.com/ru/post/222877/
https://habr.com/ru/post/258467/

Почему они обратили внимание на qbs не знаю. Даже на ЛОРе несколько эмбеддеров, юзающих этот qbs, иногда пробегают.

Так он вроде развивается их силами в отрыве от Qt-экосистемы.

Прикольно, надо сделать ещё один подход к снаряду

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

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

а если мы делаем тарболл с релизом, то 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 не помогает.

Лучше бы перешли на адекватную структуру проекта и вручную написанныe configure и makefile.

Эх, вот если meson был написан на Си, цены бы ему не было.

А так приходится мириться наличием петона в системе. Зависимость meson от python - пока единственное оправдание существования последнего.

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

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

The END

Directed by Robert B. Weide.

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

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

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

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

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

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