А вы и собираться за меня будете? Ага! Вспоминаю систему сборки для плюсов

meson?

Добавим CMake к списку вещей, которые ты ниасилил.

Не, совсем нет. Там был прикол что конфиг системы сборки был обычной программой на Си++.
Ну создаёшь экземпляр класса BuildStuff и вызываешь методы вроде addLib или там addSrc. Такое что-то.

Там DSL на подмножестве Python.

По сабжу, см. тут: https://www.reddit.com/r/cpp/comments/o01bl6/buildsystem_where_build_scripts_are_written_in_c/

https://github.com/coder137/build_in_cpp

Кажется оно, спасибо.

Попробуй кстати Meson и Waf, возможно зайдут, ведь Python сегодня имеется практически везде.

Да и выглядят перечисленные системы сборки на порядок логичнее наркоманского CMake-говнеца.

CMake я терплю поскольку он ближе всех подобрался к статусу стандарта de facto.
А Питон мне «не зашёл». В качестве скриптового языка для мелкой ерунды я использую PHP. Он хоть выглядит привычно.

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

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

Рекомендую глянуть на https://xmake.io/, там Lua и втроенный пакетный менеджер, который может использовать пакеты ряда других менеджеров. Ни CMake, ни meson мне не нравятся, а вот xmake вроде как зашёл. Не идеал, но пожалуй лучшее из того, что видел.

Просто я тут немного посношался с CMake и мне захотелось чего-то логичного.

Ну на, возьми его скорей:

Скорая помощь когда тут кому-то снова захочется поныть про сmake

Логично ты либо освоишь аду, которая практически умеет собирать сама себя (но вряд ли :)), либо логично придешь к простому велосипеду типо того что по ссылке (он там для обидного смеха над неосиляторами, конечно), либо перестанешь гнать на инструменты и поймешь как ими логично пользоваться (а заодно прочитаешь про валидную логику высказываний и поймешь что значит «логично», а не что по-твоему «звучит логично»)

И это типа лучше, чем CMake?

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

ведь Python сегодня имеется практически везде

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

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

2015

А оно не протухшее? CMake очень сильно изменился с 2015 года.

Рекомендую глянуть на https://xmake.io

Маргинальщина же. Для пет-проектов может и сойдет, но я буквально ни разу не видел проекта, его использующего.

Возможно, речь идет про build2.

Ну не настолько сильно.

А CMake сам ничего не собирает, за него это тоже делает что-то другое. Если бы без этого момента, то могло быть интересно.

Блин так и make не собирает. Собирает компилятор. Но это демагогия.

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

Компилятор компилирует, линкер компонует, система сборки собирает, генераторы систем сборки генерируют системы сборки. Тут вполне чёткая иерархия.

Компилятор компилирует, линкер компонует

Да-да-да. Ок. Так сборка - это и есть компиляция и компоновка. И это можно сделать одним компилятором (ну ок - компилятором и компоновщиком). В смысле make, cmake (и прочие) можно и не использовать. Не?

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

CMake неплох если применять vcpkg.

https://build2.org/

Попробуй кстати Meson и Waf, возможно зайдут, ведь Python сегодня имеется практически везде.

Есть реализация Meson без Питона на чистом Си, называется Muon.

Мне Meson понравился: мало писанины, нет over 9000 способов делать одно и тоже, убогих тетекторов библиотек CMake, есть система зависимостей, подпроекты, интеграция с pkg-config, поддержка кросс компиляции.

В примере xmake на их сайте у меня вызвало подозрение использования *.c, обычно это обозначает что инкрементальная сборка нормально работать не будет. И слишком много китайского языка.

Чорт, а я ведь хотел такое написать и даже название придумал такое же :)))

Ну написали без меня — и славненько. У меня бы скорее всего терпения не хватило. :)

Мне синтаксис DSL у Meson не особо нравится. Нет, конечно, он выглядит на порядок лучше наркоманского CMake, но можно было бы сделать его чуть декларативнее, как в том же QBS, от которого к сожалению отказались.

Увидел комментарий выше и вспомнил, что Meson на питоне, но хорошо, что файл сборки не на нём. Так то Meson получше CMake будет, я согласен.

В примере xmake на их сайте у меня вызвало подозрение использования *.c, обычно это обозначает что инкрементальная сборка нормально работать не будет.

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

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

От как Jam сам собирает без генерации make/ninja?

Он как Jam сам собирает без генерации make/ninja?

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

как в том же QBS, от которого к сожалению отказались

Ну не то, чтобы отказались, просто пустили в свободное плавание…

Может сталкивался кто?

А чем обычный мэйкфайл не устраивает для сборки исходных кодов?

Ну не то, чтобы отказались, просто пустили в свободное плавание…

Фирма-разработчик именно отказалась использовать QBS в своих продуктах. А то, что выбросила не в мусорное ведро, а пустила в свободное плавание - так это мода сейчас такая. Я тоже частенько вместо того, чтобы сразу выбросить ненужную вещь - отношу ее в сарай или гараж (вдруг кому потребуется или донором пойдет на запчасти). Потом приходится субботники проводить - выкидывать накопившийся хлам.

Ну так и хрен ли сокрушаешься на то, что cmake сам не собирает ничего и это типа его недостаток. Все так делают.

Если проект из пары файлов или времени овердохрена и не нужна кроссплатформенность — конечно, устраивает.

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

«Не препятствовать».

Можно сказать, что Make и Ninja - это низкоуровневые системы сборки (ассемблер).

А CMake, Meson - высокоуровневые системы сборки, используют сторонние инструменты для сборки (Make и Ninja).

Правда вот qbs и jam - это что-то вроде независимых систем сборки, низкоуровневыми их особо не назовёшь.

Морально устарел, слишком низкоуровневый, вызывает проблемы с портированием на другие системы, по производительности отстаёт от того же ninja.

Собственно, в чём существенное отличие от сырого premake?

А то, что выбросила не в мусорное ведро, а пустила в свободное плавание - так это мода сейчас такая.

Странная мода, столько лет тащить легаси поддержку выброшенного продукта. Вот и последний релиз QtCreator вполне себе содержит эту систему сборки.

А CMake сам ничего не собирает,

Блин так и make не собирает. Собирает компилятор.

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

Система исскуственного интеллекта на основе базы знаний

Makefile это такой ассемблер в мире сборочных систем

Пятизнак. Пятизнак никогда не меняется.

Морально устарел

Морально устарел только тупняк деревенских школотронов.

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

NetBSD:

Port	CPU	Machines	Latest Release
amd64	x86_64	64-bit x86-family machines with AMD and Intel CPUs	9.2
evbarm	arm	ARM evaluation boards	9.2
evbmips	mips	MIPS-based evaluation boards	9.2
evbppc	powerpc	PowerPC-based evaluation boards	9.2
hpcarm	arm	StrongARM based Windows CE PDA machines	9.2
i386	i386	32-bit x86-family generic machines ("PC clones")	9.2
sparc64	sparc	Sun UltraSPARC (64-bit)	9.2
xen	i386, x86_64	Xen Virtual Machine Monitor	9.2

acorn32	arm	Acorn RiscPC/A7000/NC and compatibles	9.2
algor	mips	Algorithmics MIPS evaluation boards	9.2
alpha	alpha	Digital Alpha (64-bit)	9.2
amiga	m68k	Commodore Amiga, MacroSystem DraCo	9.2
amigappc	powerpc	PowerPC-based Amiga boards	9.2
arc	mips	Machines following the Advanced RISC Computing spec	9.2
atari	m68k	Atari TT030, Falcon, Hades	9.2
bebox	powerpc	Be Inc's BeBox	9.2
cats	arm	Chalice Technology's Strong Arm evaluation board	9.2
cesfic	m68k	CES's FIC8234 VME processor board	9.2
cobalt	mips	Cobalt Networks' Microservers	9.2
dreamcast	sh3	Sega Dreamcast game console	9.2
emips	mips	Machines based on "Extensible MIPS"	9.2
epoc32	arm	32bit PSION EPOC PDA	none
evbsh3	sh3	Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs	9.2
ews4800mips	mips	NEC's MIPS based EWS4800 workstations	9.2
hp300	m68k	Hewlett-Packard 9000/300 and 400 series	9.2
hppa	hppa	Hewlett-Packard 9000 PA-RISC machines	9.2
hpcmips	mips	MIPS based Windows CE PDA machines	9.2
hpcsh	sh3	Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines	9.2
ia64	itanium	Itanium family of processors	none
ibmnws	powerpc	IBM Network Station Series 1000	9.2
iyonix	arm	Iyonix ARM pc	9.2
landisk	sh3	SH4 based NAS appliances by I-O DATA	9.2
luna68k	m68k	OMRON Tateisi Electronics' LUNA series	9.2
mac68k	m68k	Apple Macintosh	9.2
macppc	powerpc	Apple Power Macintosh and clones	9.2
mipsco	mips	Mips family of workstations and servers	9.2
mmeye	sh3	Brains' mmEye Multi Media Server	9.2
mvme68k	m68k	Motorola MVME 68k SBCs	9.2
mvmeppc	powerpc	Motorola MVME PowerPC SBCs	9.2
netwinder	arm	StrongARM based NetWinder machines	9.2
news68k	m68k	Sony's m68k based "NET WORK STATION" series	9.2
newsmips	mips	Sony's MIPS based "NET WORK STATION" series	9.2
next68k	m68k	NeXT 68k 'black' hardware	9.2
ofppc	powerpc	Generic OpenFirmware compliant PowerPC machines	9.2
pmax	mips	Digital MIPS-based DECstations and DECsystems	9.2
prep	powerpc	PReP (PowerPC Reference Platform) and CHRP machines	9.2
rs6000	powerpc	MCA-based IBM RS/6000 workstations	9.2
sandpoint	powerpc	Motorola Sandpoint reference platform	9.2
sbmips	mips	Broadcom SiByte evaluation boards	9.2
sgimips	mips	Silicon Graphics' MIPS-based workstations	9.2
shark	arm	Digital DNARD ("shark")	9.2
sparc	sparc	Sun SPARC (32-bit)	9.2
sun2	m68k	Sun 2	9.2
sun3	m68k	Sun 3 and 3x	9.2
vax	vax	Digital VAX	9.2
x68k	m68k	Sharp X680x0 series	9.2
zaurus	arm	Sharp C7x0/C860/C1000/C3x00 series PDA	9.2

OpenBSD Platforms:

alpha	Digital Alpha-based systems
amd64	AMD64-based systems
arm64	64-bit ARM systems
armv7	ARM based devices, such as BeagleBone, PandaBoard, CuBox-i, SABRE Lite, Nitrogen6x and Wandboard
hppa	Hewlett-Packard Precision Architecture (PA-RISC) systems
i386	Standard PC and clones based on the Intel i386 architecture and compatible processors
landisk	IO-DATA Landisk systems (such as USL-5P) based on the SH4 cpu
luna88k	Omron LUNA-88K and LUNA-88K2 workstations
macppc	Apple New World PowerPC-based machines, from the iMac onwards
octeon	Cavium Octeon-based MIPS64 systems
powerpc64	IBM POWER-based PowerNV systems

amiga	Amiga and DraCo systems with MMU
arc	ARC compatible MIPS R4k and R5k systems
armish	ARM-based appliances (by Thecus, IO-DATA, and others)
aviion	Motorola 881x0-based Data General AViiON systems
cats	StrongARM 110 Evaluation Board
hp300	Hewlett-Packard HP 9000 series 300 and 400 workstations
hppa64	Hewlett-Packard Precision Architecture (PA-RISC) 64 bit systems
loongson	Loongson 2E- and 2F-based systems, such as the Lemote Fuloong and Yeeloong, Gdium Liberty, etc.
mac68k	Motorola 680x0-based Apple Macintosh with MMU
mvme68k	Motorola 680x0-based VME systems
mvme88k	Motorola 881x0-based VME systems
palm	Palm/PXA based PDAs
pegasos	Pegasos machines by Genesi Sarl. PowerPC-based, VIA chip motherboards.
pmax	Digital MIPS-based systems
sgi	SGI MIPS-based workstations
socppc	Freescale PowerPC SoC-based machines
solbourne	Solbourne "IDT" Sparc-like S3000, S4000 and S4000DX systems
sparc	Sun sun4, sun4c, sun4e and sun4m class SPARC systems
sun3	Sun sun3 class systems
vax	Digital VAX-based systems
zaurus	Sharp Zaurus C3x00 PDAs
riscv64	64-bit RISC-V systems
sparc64	Sun UltraSPARC and Fujitsu SPARC64 systems

А ну-ка, школотрончик, расскажи при портировании на какую из систем в списке Make «вызывал проблемы»?

Ага. Т.е аргумент «cmake сам ничего не собирает» трансформируется в «cmake сам не вызывает компилятор». Да? Ну ок. И что?

1. Этот факт, кроме того, что он есть, какие-то ограничения дает?
2. Мне это видится преимуществом, т.к можно использовать разные низкоуровневые системы сборки (make, nmake, ninja и т.п.), а cmake позволяет произвести тонкую настройку этих систем, выполнить разные сложные подготовительные действия, а также действия после сборки, например скопировать зависимости или/и собрать deb-пакет.

А ну-ка, школотрончик, расскажи при портировании на какую из систем в списке Make «вызывал проблемы»?

Речь о портировании на другие ОС, а не процессоры. Может ли Make собирать одновременно с GCC, Clang и MSVC? А Meson может. Не просто так систему костылей над Make под названием Autotools придумали.

Т.е аргумент «cmake сам ничего не собирает» трансформируется в «cmake сам не вызывает компилятор». Да?

«Трансформироваться» этот тезис может, только если бы первая и вторая версии в чём-то отличались. Собирать конечную цель CMake с помощью внешних средств умеет - cmake --build . Так что речь очевидно не об этом. Речь о том, что CMake не является самостоятельно достаточным средством, чтобы собрать программу, имея кроме собственно CMake на руках только toolchain для C/C++. Если, конечно, оставить наркоманию с add_custom_command в стороне.

То есть, тут нет никакой «трансформации» тезиса - это один и тот же тезис.

а cmake позволяет произвести тонкую настройку этих систем

Ну, давай. Выйди к доске и покажи всему классу «тонкую настройку этих систем» в CMake. Я с нетерпением жду, что ты сможешь «тонко настроить» в билде для ninja или проекте для вижуал студии.

выполнить разные сложные подготовительные действия, а также действия после сборки,

Это всё умеет любая приличная система сборки, не говоря уж нормальных решениях, типа Make.

Мне это видится преимуществом

Кому ты горбатого лепишь? Ты же просто утёнок, и все «преимущества» которые ты видишь связаны исключительно с тем, что ты вообще не знаешь ни одной другой системы.

Речь о портировании на другие ОС, а не процессоры.

Так вот ты где, телепат!! Сколько лет мы тебя ждали.

Может ли Make собирать одновременно с GCC, Clang и MSVC?

Говно вопрос. Make может собирать спицами для вязания твоей бабушки.

Не просто так систему костылей над Make под названием Autotools придумали.

Прекрати быть настолько безграмотным. Автолулзы придумали не как «костыли над Make», а как костыли под UNIX / POSIX.

Странная мода, столько лет тащить легаси поддержку выброшенного продукта. Вот и последний релиз QtCreator вполне себе содержит эту систему сборки.

Тем не менее - в Qt6 основной системой сборки является cmake. А QtCreator не содержит это систему, а поддерживает как один из вариантов. Поддерживать продукт, который более не развивается - довольно легко, можно ничего не менять в уже написанном коде.

В том то и дело, что qbs вполне себе развивается сообществом, последний релиз (1.22) пару месяцев назад выкатили. Так что поддерживать ничего не меняя в коде так себе получится.

Говно вопрос. Make может собирать спицами для вязания твоей бабушки.

Если только по методу «восход солнца вручную».

Прекрати быть настолько безграмотным. Автолулзы придумали не как «костыли над Make», а как костыли под UNIX / POSIX.

А Make как будто не часть костылей UNIX / POSIX.

В том то и дело, что qbs вполне себе развивается сообществом, последний релиз (1.22) пару месяцев назад выкатили.

Тем не менее, исходники Qt6 можно собрать только cmake или qmake. qbs - в пролете! Никому не нужное 5-е колесо в телеге.