Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск сборочной системы Meson 1.12.0"	+/–
Сообщение от opennews (??), 11-Авг-26, 08:37
Опубликован релиз сборочной системы Meson 1.12.0, которая используется для сборки таких проектов, как X.Org Server, Mesa, QEMU, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK. Код Meson написан на языке Python и поставляется под лицензией Apache 2.0... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=66060
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

3. Сообщение от Ык (?), 11-Авг-26, 09:26	–2 +/–
Кто нибудь пользовался? Как это стстема по сравнению с crate или maven?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от Анонимный аноним (?), 11-Авг-26, 09:30	–1 +/–
Ее скорее надо сравнивать с cmake и gnu autotools. Она лучше чем эти оба. ИМХО.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5, #6, #15

5. Сообщение от Sm0ke85 (ok), 11-Авг-26, 09:34	–2 +/–
>Она лучше чем эти оба. ИМХО. ``` поставляется под лицензией Apache 2.0. ``` Нет, хуже))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

6. Сообщение от Аноним (6), 11-Авг-26, 09:42	–2 +/–
Невозможно сделать хуже cmake, который вместо поддержки pkg-config пихает кучу своих cmake файлов при установке собранного им софта. Аутотулз вообще страшный мультивибратор, где скрипт собирает скрипт, который собирает скрипт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #10, #11, #12, #18

9. Сообщение от Сладкая булочка (?), 11-Авг-26, 13:00	+/–
> Код Meson написан на языке Python В который хотят добавить раст как сборочную зависимость. Думайте!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #14, #19, #22, #59

10. Сообщение от No Name (?), 11-Авг-26, 13:17	+6 +/–
>Невозможно сделать хуже cmake, который вместо поддержки pkg-config пихает кучу своих cmake файлов при установке собранного им софта. Ничего CMake никуда не пихает, это делают криворукие программисты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

11. Сообщение от Аноним (11), 11-Авг-26, 14:09	+4 +/–
> cmake, который вместо поддержки pkg-config Разуй глаза, эксперт: https://cmake.org/cmake/help/latest/module/FindPkgConfig.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

12. Сообщение от Аноним (12), 11-Авг-26, 15:19	+1 +/–
> Невозможно сделать хуже cmake, который вместо поддержки pkg-config пихает кучу своих cmake файлов при установке собранного им софта. pkg-config устаревший шлак который умеет только отдать путь к инклудам и имя библиотеки, и нет, это НЕ является зависимостью, которую должны отдавать подобные инструменты. Между тем "куча своих cmake файлов" поддерживается тем же meson'ом и работает из коробки в отличие от pkgconfig.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #16, #17

13. Сообщение от Аноним (12), 11-Авг-26, 15:20	+1 +/–
Согласен, пока не добавят внимания не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

14. Сообщение от Аноним (14), 11-Авг-26, 15:28	+1 +/–
Питон даже как сам как сборочная зависимость для плюсов не нужен вообще. Итого: мезон не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #21

15. Сообщение от Ivan_83 (ok), 11-Авг-26, 15:40	+/–
Кажется что угодно лучше автотулсов :) Насчёт cmake - спорное. Думаю лучше для тех у кого нет отторжения к питоновскому синтаксису. У cmake синтаксис какой то свой и он так себе. Честно говоря мне всё это надоело и последнее время я пишу свою сборочную систему на shell script. У меня проекты маленькие, на С, зависимостей очень мало или совсем нет и эти жуткие монстры мне нафик не упали. Юзать gmake в принципе можно было, по сути оно мало чем отличается от shell script (кроме расширения синтаксиса и один интерпретатор всегда совместим сам с собой), но тоже часто выглядит слишком жирной зависимостью для моих проектов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #20, #37, #39, #63

16. Сообщение от Аноним (11), 11-Авг-26, 15:42	+/–
> pkg-config устаревший шлак который умеет только отдать путь к инклудам и имя библиотеки ...и флажки компиляции, намертво прибитые к конкретному компилятору.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #71

17. Сообщение от Ivan_83 (ok), 11-Авг-26, 15:42	+/–
Насколько я понял, авторы месона как раз наоборот стараются вообще ничего не костылить сами и полагаются на pkg-config по максимуму. Когда пару лет назад была в последнем проблема с сортировкой/порядком то починить это костылём из месона было не возможно в принципе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #46

18. Сообщение от Ivan_83 (ok), 11-Авг-26, 15:46	–1 +/–
Насколько я видел - там принято корябать свои cmake файлы для того что мог бы сделать pkg-config, в ряде случаев. Автотулз наверное был не плох лет 30 назад, но такое ощущение что в него напихали всякого по максимуму. Да и портянки которые он генерит и портянки из которых он генерит читать не особо удобно :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

19. Сообщение от Ivan_83 (ok), 11-Авг-26, 15:46	+/–
Ну вот да, поэтому я пишу свою сборочную систему на shell script :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #25, #29

20. Сообщение от Аноним (11), 11-Авг-26, 15:46	+3 +/–
> пишу свою сборочную систему на shell script > У меня проекты маленькие, на С > эти жуткие монстры мне нафик не упали. > выглядит слишком жирной зависимостью для моих проектов. Золотая классика хэллоуворлдов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #26

21. Сообщение от Ivan_83 (ok), 11-Авг-26, 15:49	–1 +/–
Так выбора в индустрии почти нет. Месон на вид самое простое и адекватное для тех кого не тошнит от питона при одном только виде. Есть cmake, но он у меня при сборке требует месона... да и синтаксис там не очень удобный, чего только end() стоит. Да и всякого прочего туда понапихали последние годы тоже, типа курла чтобы сам умел качать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #23, #60, #65

22. Сообщение от Аноним (11), 11-Авг-26, 15:49	+3 +/–
>> Код Meson написан на языке Python > В который хотят добавить раст как сборочную зависимость. Думайте! Тебе в Firefox и Android его уже давно добавили. И что, надумал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #30, #32

23. Сообщение от Аноним (11), 11-Авг-26, 15:52	+1 +/–
> Есть cmake, но он у меня при сборке требует месона Чиво? Для его сборки кроме компилятора и make ничего не требуется: https://github.com/kitware/cmake#building-cmake-from-scratch
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #24

24. Сообщение от Ivan_83 (ok), 11-Авг-26, 16:13	+/–
Ну вот а меинтейнер во фре как то не осилил сделать так чтобы cmake собирался без meson. Возможно и меинтейнеры других проекто оказались не лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

25. Сообщение от Аноним (12), 11-Авг-26, 16:14	+/–
Не трать время, лучше просто вывали исходники. Никто в твоём шелле не работающим нигде кроме твоего локалхоста разбираться не будет, и просто накадает CMakeLists.txt из одной строчки с `add_executable` которую ты не осилил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #27

26. Сообщение от Ivan_83 (ok), 11-Авг-26, 16:23	+/–
Нет, классика это когда для сборки одного .c файла в самом файле написана в коментах строчка как его собрать :) У меня несколько таких проектов на гитхубе лежат - даже как то стрёмно было туда cmake писать. Тут же вполне себе компактная система которая умеет почекать флаги компилятора и прочее. На моих проектах получается что шелл скрипт с описанием занимает меньше буков чем точно такое же на cmake. Синтаксически/идеологически похожа на мой другой недавний проект: https://github.com/rozhuk-im/chroot_env Притом из забавного: оно быстрее cmake работает, когда флаги/функции/символы надо прочекать. Многопоточную сборку я тоже относительно легко прикрутил. Для примера оно lua собирает у меня на полторы секунды, те от первого запуска до готового бинарника и либы. И да, я примерно представляю что оно будет работать на ограниченном числе платформ и не очень для больших проектов, но мне этого достаточно. Как раз замена cmake там где он излишен. Плюс простота из коробки: запустил make.sh и получил релизные бинарники.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #28

27. Сообщение от Ivan_83 (ok), 11-Авг-26, 16:24	+/–
Да есть у меня исходники, всё что больше одного .c файла и так содержит cmake.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

28. Сообщение от Аноним (11), 11-Авг-26, 16:36	+/–
> Как раз замена cmake там где он излишен. Излишне - это, при наличии готового инструмента, гробить свою единственную жизнь на изобретение корявого велосипеда. Для студентоты такой подход еще приемлем, ибо является частью обучения. Но если ты уже взрослый детина, то тебе можно только посочувствовать: рано или поздно (а скорее всего, уже) ты сам будешь горько жалеть за бездарно потраченное время, которое уже не вернуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31

29. Сообщение от Сладкая булочка (?), 11-Авг-26, 16:47	+/–
> Ну вот да, поэтому я пишу свою сборочную систему на shell script > :) Есть muon, но не полностью совместим
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #33

30. Сообщение от Сладкая булочка (?), 11-Авг-26, 16:48	+1 +/–
>>> Код Meson написан на языке Python >> В который хотят добавить раст как сборочную зависимость. Думайте! > Тебе в Firefox и Android его уже давно добавили. И что, надумал? Ну firefox'у это не помогает, а ведроидом не пользуюсь. Может хватит уже эти прмеры приводить? В ff большинство кода - это c++ и js.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #34

31. Сообщение от Ivan_83 (ok), 11-Авг-26, 16:52	+/–
Я согласен с тем, что это хорошо для обучения. Но скажем так, раньше мне знаний не хватало чтобы этим занятся. И сейчас много интересного узнаю. Я не считаю что это работа целиком на корзину, я чётко обозначил нишу: небольшие С проекты, там всё остальное избыточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

32. Сообщение от Ivan_83 (ok), 11-Авг-26, 16:54	+/–
А вы не понимаете разницу? Одно дело когда тебе продают/отдают готовый продукт, а другое дело когда ты сам с этим возишься. В первом случае наличие дрыста - это интимная проблема создателей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #35

33. Сообщение от Ivan_83 (ok), 11-Авг-26, 17:02	+/–
Не знал :) На фре его прикрутили, но так понял не юзается. Но как решение проблемы всё равно мне не очень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

34. Сообщение от Аноним (11), 11-Авг-26, 17:11	+/–
> Ну firefox'у это не помогает Ты сказал? > ведроидом не пользуюсь Пришло время офигительных историй! Давай, расскажи мне, что у тебя кнопочник вместо смарта, чтобы коварные корпы не отслеживали. > Может хватит уже эти прмеры приводить? Нет, не хватит, ибо ты лицемерно кушаешь ФФ, воюя при этом против Раста. >>> Код Meson написан на языке Python >> В который хотят добавить раст как сборочную зависимость. Думайте! >  В ff большинство кода - это c++ и js. А в cpython Раста сейчас вообще нет, но это не помешало тебе здесь всплыть со своей священной войной против мельниц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #54

35. Сообщение от Аноним (11), 11-Авг-26, 17:16	+/–
> А вы не понимаете разницу? > Одно дело когда тебе продают/отдают готовый продукт, а другое дело когда ты сам с этим возишься. О какой разнице ты говоришь? Что Firefox, что Python ты либо готовый качаешь из репы, либо собираешь сам. > В первом случае наличие дрыста - это интимная проблема создателей. А во втором - тех, кто "возится". И?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #36

36. Сообщение от Ivan_83 (ok), 11-Авг-26, 17:29	+/–
Так ты постоянно тыкаешь в пользователей андройда: "ааа там дрыст, ты тоже заляпался!" - а это не так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #40

37. Сообщение от Анонимный аноним (?), 11-Авг-26, 17:33	+/–
И зачем твоя shell-скрипт система, если она будет прибита к unix? Для unix в сто раз проще и лучше написать просто Makefile. Сборочная система нужна чтобы под разные ОС собирать, в том числе не unix.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #38

38. Сообщение от Ivan_83 (ok), 11-Авг-26, 17:43	+/–
Венда мне не нужна, а sh есть везде, притом что gmake/bmake может и не быть. Кроме того, насколько я видел, gmake/bmake по сути от sh отличаются только синтаксисом, сами по себе они флаги компилятора и прочее не умеют. Для проверки вот этого всего нагородили автотулсы поверх. У меня именно что можно указать список флагов компилятора, линковщика, функции, символы и оно проверит что оно есть в системе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #45

39. Сообщение от Аноним (12), 11-Авг-26, 17:44	+1 +/–
> У меня проекты маленькие, на С, зависимостей очень мало или совсем нет и эти жуткие монстры мне нафик не упали. Эх, некому сейчас детям рассказать что такое сложность и где мы за неё платим, а где нет. Тебя же не смущает что для запуска твоих поделок нужен такой "монстр" как ядро ОС? По той же причине не должен смущать cmake. Вся его сложность от тебя скрыта, он есть на любой системе где собирают софт из исходников, и для хелловорлда `CMakeLists.txt` будет состоять из одной строчки `add_executable(helloworld helloworld.c)`, при этом работать на невообразимом количестве систем и платформ, генерить проекты для IDE, кросскомпилировать и whatnot. CMake при этом может хоть терабайт занимать и требовать отдельного датацентра - для тебя и для тех кто собирает твой проект чтобы опакетить или законтрибутить, сложность будет равна одной строке. > последнее время я пишу свою сборочную систему на shell script. Заметь, она уже заняла твоё последнее время, которое можно было потратить на что-то полезное, и займёт ещё, у тебя через месяц потому что ты забудешь что она делает, и любому кому потребуется собрать твой код придётся прочитать всю простыню твоей системы, потому что, в отличие от cmake, она кастомна и непредсказуема. При этом работать она нигде кроме твоего локалхоста не будет, и на нём сломается когда ты переедешь на другой дистрибутив, для сборки пакетов она будет категорически непригодна, и не будет уметь вообще ничего что ожидается от системы сборки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #41

40. Сообщение от Аноним (11), 11-Авг-26, 17:45	+/–
> Так ты постоянно тыкаешь в пользователей андройда: "ааа там дрыст, ты тоже заляпался!" - а это не так. Я тыкаю не во всех пользователей Андроида, а в конкретных лицемеров, которые воюют против Раста, кушая софт, который на нем написан. > ааа там дрыст, ты тоже заляпался!" - а это не так Ну вот видишь как у вас, лицемеров, устроены виляния? "Я не заляпался Растом, ведь я на нем вообще не пишу, а лишь потребляю уже собранное! И сейчас вам поведаю, почему Раст - это плохо"."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #42

41. Сообщение от Ivan_83 (ok), 11-Авг-26, 17:55	+/–
Так и с помощью cmake ты пакет не соберёшь пока автор туда не навалит тонну кода с описание как это делать. В остальном я не то что бы спорю, но ведь есть достаточно много проектов где есть только makefile, который от моей сборочной системы отличается ВСЕГДА в худьшую сторону ибо там нет функций для быстрой и лёгкой проверки компилятора и среды на нужные функционал. Использование cmake (насколько я знаю) всегда требует несколько раздельных вызовов, что так же не удобно. Ещё раз: я не создаю конкурента cmake/meson/autotools, это скорее замена gmake/bmake с отдельными функциями как в cmake/meson - тот же pkg-config из коробки через готовые обвязки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #47

42. Сообщение от Ivan_83 (ok), 11-Авг-26, 17:59	+1 +/–
Меня вопросы лицемерия не интересуют - это ваша личная проблема восприятия действительности. Пользователю андройда, фф - вообще пофик что там и как там, лишь бы работало. И оно точно так же работало когда никакого раста в природе не было. Но об этом вы почему то забываете, как и забываете про то, что раст это всего лишь пыль/паразит и небольшой кусочек всей экосистемы, и что там намного больше кода на других ЯП. Что будет если убрать весь код на раст из фф и андройда - ничего страшного. Что будет если убрать код на С/С++/джаве - всё сломается, оно изначально на этом писалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #43

43. Сообщение от Аноним (11), 11-Авг-26, 18:26	–1 +/–
> Меня вопросы лицемерия не интересуют Ну естественно, ведь ты же сам лицемер. > это ваша личная проблема восприятия действительности Нет, проблема тут лишь в том, что такие воины загаживают тут комментарии. > Пользователю андройда, фф - вообще пофик что там и как там, лишь бы работало. ...но как только речь заходит о каком-либо другом софте, то в комментариях всплывают Вани83 и прочие сладкие булочки с рассказами, как же всем от Раста плохо. > Что будет если убрать весь код на раст из фф и андройда - ничего страшного > Что будет если убрать код на С/С++ > оно изначально на этом писалось А зачем в принципе убирать какой-либо код? Это типа был аргумент против Раста? А так большинство нового кода в Андроиде "изначально пишется" как раз на Rust, а не C++. Была же новость тут. Поэтому если ты собрался "убрать" весь растовый код, то придется переписать его на С++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #48

45. Сообщение от Анонимный аноним (?), 11-Авг-26, 19:56	+/–
make тоже есть везде. очередная сборочная система, которой даже еще нет и это просто идеи в голове, это просто проявление NIH-синдрома и желания попиариться в комментах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #50

46. Сообщение от Аноним (12), 11-Авг-26, 19:59	+/–
Авторы месона не могут выбирать на что им полагаться - они обязаны полагаться на то что используется в экосистеме СПО, а используется и pkgconfig, и cmake файлы, и ничего (т.е. инклуды и сошки нужно искать по известным именам в известных каталогах). Всё то же самое делает и cmake.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #51

47. Сообщение от Аноним (12), 11-Авг-26, 20:29	+1 +/–
> Так и с помощью cmake ты пакет не соберёшь пока автор туда не навалит тонну кода с описание как это делать. Я тебе повторяю - никаких "тонн" не надо. Надо только то что надо - ровно одна строчка для сборки бинарника из списка исходников. Ровно одна строчка для добавления зависимости. Ровно одна строчка для добавления теста. Декларативно и максимально коротко, ни байта описания КАК собирать и как искать зависимости тебе не нужно. Это и называется сборочная система. > В остальном я не то что бы спорю, но ведь есть достаточно много проектов где есть только makefile Странно было бы думать что ты единственный невежда. Потом, ещё полно недогнившего легаси до-cmake времён. > который от моей сборочной системы отличается ВСЕГДА в худьшую сторону ибо там нет функций для быстрой и лёгкой проверки компилятора и среды на нужные функционал. Открою секрет - никому эти проверки нахрен не сдались. Во-первых, за последние 40 лет POSIX экосистема достаточно гомогенизировалась, и всякие недоделки типа svr4 и pdp-11 со своим уникальным endianess благополучно вымерли. Не нужно больше компилировать conftest'ы дольше чем само приложение как делал мерзотный autocrap, а можно просто использовать стандартные вызовы и быть уверенным что это будет работать на всём зоопарке от netbsd до haiku. Во-вторых, это изначально был ущербный подход, потому что если что-то не поддерживается, то у тебя просто упадёт компиляция, и не надо поддерживать и тратить время на запуск комплекта проверок. Остаётся кейс когда тебе в зависимости от фичи нужно скомпилить разный код, и для этого есть try_compile. Тоже всего одна строка, и точно лучше чем сделано у тебя. А вот чем твоя поделка отличается в "худьшую" сторону от любой системы сборки, даже богомерзкого scons, и не перечислить, просто потому что ты не знаешь сколько всего она должна уметь, и уметь стандартным способом, а ведь именно от этого незнания ты и стал её писать. Давай, например, с простого - как у тебя реализована инкрементальная сборка, как передаются извне компилятор и его флаги, и как выглядит установка приложения в систему. > Использование cmake (насколько я знаю) всегда требует несколько раздельных вызовов, что так же не удобно. Да, необходимость писать `cmake && cmake --build` ставит на нём крест. Что же теперь делать. > Ещё раз: я не создаю конкурента cmake/meson/autotools, это скорее замена gmake/bmake с отдельными функциями как в cmake/meson - тот же pkg-config из коробки через готовые обвязки. Я прекрасно понимаю что ты создаёшь, и прекрасно понимаю что пользоваться этим будет невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #49

48. Сообщение от Ivan_83 (ok), 11-Авг-26, 20:49	+/–
> Ну естественно, ведь ты же сам лицемер. И чо? > А зачем в принципе убирать какой-либо код? Это типа был аргумент против Раста? Да. > Поэтому если ты собрался "убрать" весь растовый код, то придется переписать его на С++. ЫЫ это легко сделает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #56

49. Сообщение от Ivan_83 (ok), 11-Авг-26, 21:12	+/–
> Надо только то что надо - ровно одна строчка для сборки бинарника из списка исходников. Ровно одна строчка для добавления зависимости. Ровно одна строчка для добавления теста. Я видел с десяток проектов на cmake и там было больше строчек. > Потом, ещё полно недогнившего легаси до-cmake времён. Так у них с gmake прекрасно всё собирается, зачем им ещё что то? > Открою секрет - никому эти проверки нахрен не сдались. Странно слышать, учитывая что есть как минимум clang и gcc а так же разные версии разных ОС и разных библиотек. Часто проще написать проверку что флаг или функция есть чем городить кучу проверок соответствия ОС, компилятора и хз чего ещё. > Остаётся кейс когда тебе в зависимости от фичи нужно скомпилить разный код, и для этого есть try_compile Ну вот я примерно это и реализовал, для функций и символов. > А вот чем твоя поделка отличается в "худьшую" сторону от любой системы сборки, даже богомерзкого scons, и не перечислить, просто потому что ты не знаешь сколько всего она должна уметь, и уметь стандартным способом, а ведь именно от этого незнания ты и стал её писать. Повторяю ещё раз: для простых программ вполне хватает gmake, который от моей поделки отличается в худьшую сторону. И мне не так уж и много надо, поэтому подход выглядит вполне рабочим. Но быть может лет через 5-10 я признаю что это был путь в никуда, не вижу в этом ничего плохого. > Давай, например, с простого - как у тебя реализована инкрементальная сборка, как передаются извне компилятор и его флаги, и как выглядит установка приложения в систему. Никак не реализовано, как и в большинстве gmake файлов. Но я уже пробовал игратся с тем чтобы можно было "докомпиливать" только изменённые файлы, это на самом деле не сложная фича: дёрнуть компилятор чтобы он выдал все инклюдесы, найти самый свежий файл и проверить что его дата старее чем время компиляции. В примитивном случае можно компилятор не дёргать а просто скопировать время мобификации с .с файна на .о файл, но это чревато если инклюд поредактируют... Всё передаётся через переменные окружения. До установки я ещё не дошёл, в целом будет просто функция target_install() которую каждый для своего проекта сам будет описывать. Для 1-10 результирующих файлов/папок руки не отвалятся. Куда ставить - видимо будет дефолты от профиля ОС + оверрайд через переменные окружения. > Да, необходимость писать `cmake && cmake --build` ставит на нём крест. Что же теперь делать. Но это же не полная последовательность действий, зачем вы лукавите. Это будет insource сборка которая всё загадит. > Я прекрасно понимаю что ты создаёшь, и прекрасно понимаю что пользоваться этим будет невозможно. Ну да, запустить make.sh - это нивазможное действие :) А насчёт переносимости: у меня некоторые проекты вообще только под фрю, уж там то оно не сломается. На убунтах я без проблем проверю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #52

50. Сообщение от Ivan_83 (ok), 11-Авг-26, 21:19	+2 +/–
Да какой make то? На фре это bmake, который с gmake не совсем совместим. Или вы из этих, у которых sh=bash и про другое они не слышали? И потом, как я писал выше, gmake не очень сильно от sh отличается, а у меня уже есть некоторый функционал от cmake и удобные функции/обёртки. В остальном таких как вы слушать - сидеть без прогресса, как полный дурак, и даже ничего не узнать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

51. Сообщение от Ivan_83 (ok), 11-Авг-26, 21:21	+/–
Мне после беглого знакомства с месон казалось что они пошли по другому пути и стараются сами ничего не костылить внутри, в отличии от cmake с его либой костылей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

52. Сообщение от Аноним (12), 11-Авг-26, 23:07	+1 +/–
> Я видел с десяток проектов на cmake и там было больше строчек. Рад за тебя, это чему-то из мной сказанного противоречит? > Так у них с gmake прекрасно всё собирается, зачем им ещё что то? Во-первых, не прекрасно - ты сам уже назвал как минимум две функции которых в gmake нет, и достаточно посмотреть на количество патчей к мейкфайлам в репозиториях. Я могу назвать не менее десятка ошибок которые в самописных мейкфайлах делают постоянно, которые в cmake при этом невозможны. Во-вторых, мы всё-таки говорим не о cmake vs gmake, а о cmake vs. самописная дрисня. > Странно слышать, учитывая что есть как минимум clang и gcc а так же разные версии разных ОС и разных библиотек. Перечисли что в твоих хелловорлдах так отличается что тебе нужна разные реализации на разных компиляторах и ОС? Что до библиотек, просто требуют версию >= X.Y. KISS. Не нужны никакие проверки. > Повторяю ещё раз: для простых программ вполне хватает gmake, который от моей поделки отличается в худьшую сторону. От твоей поделки ничего не может отличаться в худшую сторону, потому что самописный велосипед это дно которое нельзя пробить. Он не умеет ничего чего не умела бы современная система сборки, при этом он потратил твоё время, и потратит время каждого кому потребуется собрать твой код. > Никак не реализовано > До установки я ещё не дошёл Ну понятно. Действительно, есть на что потратить 5-10 лет. > Но это же не полная последовательность действий, зачем вы лукавите. > Это будет insource сборка которая всё загадит. Это вы лукавите - пишете что кому-то там якобы gmake хватает, при том что insource сборка там это почти всегда единственный вариант. И проблемой это не является - во-первых, это "загаживание" нигде не видно, во-вторых, есть git clean. Ну добавь `..` если хочешь outsource, это будет последний гвоздь в гроб cmake. > Ну да, запустить make.sh - это нивазможное действие :) Никакой нормальный человек не запустит make.sh не прочитав его, уже хотя бы потому что если кто-то написал свою систему сборки, доверять ему нельзя, почти гарантированно оно делает `curl | sudo sh` и срёт в систему по рандомным путям, хотя очень маловероятно что она дойдёт до установки, и тогда её понадобится не только прочитать, но и отладить и исправить. Фигня какая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #53

53. Сообщение от Ivan_83 (ok), 11-Авг-26, 23:34	+/–
> Рад за тебя, это чему-то из мной сказанного противоречит? То что я реально видел на практике отличается от того что вы описываете. > Во-вторых, мы всё-таки говорим не о cmake vs gmake, а о cmake vs. самописная дрисня. > От твоей поделки ничего не может отличаться в худшую сторону, потому что самописный велосипед это дно которое нельзя пробить. Повторяю: sh = gmake, особой разницы нет. От того что в обычных проектах нечто называется makefile а не make.sh ничего по сути не меняется. > Перечисли что в твоих хелловорлдах так отличается что тебе нужна разные реализации на разных компиляторах и ОС? hardening флаги компилятора, включатели/выключатели варнингов которые между компитоярами тоже отличаются. Что касается ОС то мне нужны проверки наличия функций и символов, у меня, например, разные эвент бэкенды для линуха - epoll и для bsd - kqueue(), не говоря о том, что местами у меня есть собственные реализации отсутствующих функций, той же strlcpy(). Можешь более подробно почитать тут: https://github.com/rozhuk-im/ssdpd/blob/master/CMakeLists.txt или в соседних моих проектах. > Ну понятно. Действительно, есть на что потратить 5-10 лет. А ты что предлагаешь? Писать cmake и пить пиво? - так это топтание на месте, без учёбы и развития. > Это вы лукавите - пишете что кому-то там якобы gmake хватает, при том что insource сборка там это почти всегда единственный вариант. Чувак, ты споришь ради спора. Вот так обычно cmake проекты сейчас компеляют: mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=true .. make -j 16 Да, ты можешь записать это в одну строчку или засунуть в шелл скрипт, но это то как изначально без костылей оно работает. У меня сразу make.sh. > Никакой нормальный человек не запустит make.sh не прочитав его, уже хотя бы потому что если кто-то написал свою систему сборки Это конечно плохой аргумент, но нонче вообще многое ставится через curl | sh - так что многие копипастя в терминал не приходя в сознание всякую гадость. В остальном ты опять шизу пишешь, потому что ровно тоже самое пишут в makefile который запускают через gmake: install: dummy     cd src && $(MKDIR) $(INSTALL_BIN) $(INSTALL_INC) $(INSTALL_LIB) $(INSTALL_MAN) $(INSTALL_LMOD) $(INSTALL_CMOD)     cd src && $(INSTALL_EXEC) $(TO_BIN) $(INSTALL_BIN)     cd src && $(INSTALL_DATA) $(TO_INC) $(INSTALL_INC)     cd src && $(INSTALL_DATA) $(TO_LIB) $(INSTALL_LIB)     cd doc && $(INSTALL_DATA) $(TO_MAN) $(INSTALL_MAN) uninstall:     cd src && cd $(INSTALL_BIN) && $(RM) $(TO_BIN)     cd src && cd $(INSTALL_INC) && $(RM) $(TO_INC)     cd src && cd $(INSTALL_LIB) && $(RM) $(TO_LIB)     cd doc && cd $(INSTALL_MAN) && $(RM) $(TO_MAN) local:     $(MAKE) install INSTALL_TOP=../install это кусок из lua. Чтобы это портировать в sh нужно просто install поменять на target_install() и добавить скобочек. (ну и враппер-запускатор вида: exec target_${1}) И этому решению/коду больше чем cmake лет. В общем ты постоянно выдаёшь свой узкий взгляд за якобы единственную истину в мире.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #55

54. Сообщение от Сладкая булочка (?), 12-Авг-26, 00:12	–1 +/–
>> ведроидом не пользуюсь > Пришло время офигительных историй! Давай, расскажи мне, что у тебя кнопочник вместо > смарта, чтобы коварные корпы не отслеживали. Жаль, что тебе сложно в это поверить. В основном мне нужен только прием смс и звонки в исключительных случаях. >> Может хватит уже эти прмеры приводить? > Нет, не хватит, ибо ты лицемерно кушаешь ФФ, воюя при этом против > Раста. >>>> Код Meson написан на языке Python >>> В который хотят добавить раст как сборочную зависимость. Думайте! >>  В ff большинство кода - это c++ и js. > А в cpython Раста сейчас вообще нет, но это не помешало тебе > здесь всплыть со своей священной войной против мельниц. Как же у тебя пригорает... Это хорошо)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

55. Сообщение от Аноним (11), 12-Авг-26, 01:34	+1 +/–
> Повторяю: sh = gmake, особой разницы нет. > От того что в обычных проектах нечто называется makefile а не make.sh ничего по сути не меняется. > Писать cmake и пить пиво? - так это топтание на месте, без учёбы и развития. Ваня, если бы ты действительно обучался, а не страдал вот этой туфтой, то знал бы, что Make в свое был создан БУКВАЛЬНО от того, чтобы не мучаться с Shell-скриптами. То есть еще в середине 70-х люди поняли, что это тупик. А ты сейчас, спустя пол-века, называешь этот подход "развитием". И пишешь свой убогий велосипед БУКВАЛЬНО потому, что в силу своего заторможенного развития так и не понял, что такое make, чем он отличается от shell и зачем вообще нужен. Извини, но тебе выше все правильно написали: "это дно которое нельзя пробить".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #57

56. Сообщение от Аноним (11), 12-Авг-26, 02:12	+/–
>> Ну естественно, ведь ты же сам лицемер. > И чо? То, что ты сам же дискредитируешь свою войну. Не соображаешь, да? >> А зачем в принципе убирать какой-либо код? Это типа был аргумент против Раста? > Да. Что "да"? То, что ты более нелепого аргумента придумать не смог - это и так очевидно  Главный же вопрос был: зачем? >> Поэтому если ты собрался "убрать" весь растовый код, то придется переписать его на С++. > ЫЫ это легко сделает. ЫЫ и обратное легко сделает. А так смешно, конечно, что ты грезишь ИИ-переписыванием именно с Rust на C++ учитывая, что в Андроиде с Хромом в приоритете именно Раст, и оба проекта пишутся одним из главных идеологов ИИ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #58

57. Сообщение от Ivan_83 (ok), 12-Авг-26, 03:19	+/–
Может в 70е годы это и был тупик, но сейчас вполне себе есть переносимые шелл скрипты и всё как то утряслось, по крайней мере особых проблем нет если не юзать специфичные флаги и утилиты, базовый набор везде более-менее одинаковый. И если что я уже имел опыт костыляния даже базовых утилит из классических makefile когда делал чтобы сборка опенврт работала на фре. (и таки да, я собирал работающие опенврт образы на фре) На самый крайний случай можно тупо потребовать bash в качестве интерпретатора. В остальном же, если бы я слушал таких как вы - я бы жил намного хуже. Даже хождение по тупикам учит. Однажды я вытаскивал фрёвый IP стёк в нетграф ноду, чтобы у меня было что то типа ng_ethernet где свой MAC и свой IPv4. Делалось это чтобы пропускать броадкасты (от одной игрулины) через домашний впн сервер в домашнюю локалку и обратно. Заняло кажется месяца 2 или больше, и даже PoC заработал. Потом я понял какие правила и как можно было записать в PF для получения такого же эффекта. Изначально были способы решения задачи проще, и те что гуглились и те что я потом осознал уже сам. Если бы я изначально пошёл этим простым путём то никогда бы не узнал как сети работают на низком уровне и много всего интересного о внутрянке фри. И эти знания до сих пор прекрасно монетизируются. Ещё как то раз мне нужна была ассимтеричная крипта у меня в приложении...и я опять пошёл путём самурая - сам реализовал с нуля ECDSA (одна из десятка-двух реализаций в мире). Можно было зацепить опенссл или ещё что за пол часа, а я потратил пол года. Это те знания что в вузах то не часто дают (такое обычно курсовая-дипломная), плюс сопутствующие соседние направления... Даже мои портирования фрибсд на старый арм, который безвозвратно потерялся при переезде и сам код можно было почти весь выкинуть/невозможно переиспользовать - всё равно многому меня научил что потом пригождалось. Даже глупая возня с запуском/портированием ужасного питоноподелия HomeAssistant на фрю - и то окупилось уже на работе. А теперь какой то чел будет мне рассказывать что я зря трачу время на систематизацию и приобретение новых знаний о работе компиляторов, линкеров, сборочных систем и обеспечение кроссплатформенности? Серьёзно!? Может у вас и однообразная работа на конвеерее в стиле крути-толкай, но у меня обычно широкий кругозор пригождается, даже навыки в схемотихнике/пайке лишними не оказались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #61

58. Сообщение от Ivan_83 (ok), 12-Авг-26, 03:28	+/–
Да - аргумент против раста. Вы тыкаете растом как будто без него жить нельзя и всё сломается, я показал что в ваших примерах раста изначально не было и они прекрасно работали без него. И растокода там не так уж много, переписать это обратно на С не будет большой проблемой, в отличии от переписывания всего подряд на раст. И ЫЫ и раст - хайп проекты. Есть много ровестников раста решающих те же проблемы сходным образом, но их не захайпили фанатики и о них почти ничего не слышно. Хайп на раст уже кончается: он не проявил себя как хороший язык для разработки с нуля, это многие поняли на практике. Ещё лет 5 и появятся злые ненавистники которые будут рассказывать про ужасы рефакторинга легаси растокода. Пока оно ещё под ковром, фанатики создают видимость что всё общество обожает язык, только неудачники его не любят. Это я могу легко говорить свободно - мне плевать что обо мне думают люди которые не платят мне деньги и физически до меня дотянутся не могут :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #62

59. Сообщение от Илья (??), 12-Авг-26, 05:38	+/–
> Python ужас. Он, надеюсь, раз в три недели не перестаёт работать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

60. Сообщение от Илья (??), 12-Авг-26, 05:39	+/–
> для тех кого не тошнит от питона при одном только виде спасибо, ты подобрал замечательные слова. Теперь я понимаю, что меня тошнит от питона при одном только виде
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

61. Сообщение от Аноним (72), 12-Авг-26, 05:50	+1 +/–
>> Ваня, если бы ты действительно обучался, а не страдал вот этой туфтой, то знал бы, что Make в свое был создан БУКВАЛЬНО от того, чтобы не мучаться с Shell-скриптами. > Может в 70е годы это и был тупик, но сейчас вполне себе есть переносимые шелл скрипты и всё как то утряслось Ты вообще не понял, о чем я тебе написал. И Make, и Shell с черт знает с каких времен оба прописаны в POSIX и потому являются переносимыми, да только речь не об этом. > А теперь какой то чел будет мне рассказывать что я зря трачу время на систематизацию и приобретение новых знаний о работе [...] сборочных систем и обеспечение кроссплатформенности? Серьёзно!? Конечно, серьезно. Ты написал корявый велосипед для хэллоуворлдов БУКВАЛЬНО из-за отсутствия знаний и даже банального не понимания, зачем нужен тот же make. Ты что называется похерил и приобретение знаний, и тем более их систематизацию - и теперь из-за их отсутствия сидишь и изобретаешь корявые велосипеды для своих хэллоуворлдов, навсегда застряв на том этапе, который нормальный человек проходит еще на первых курсах института, а то и школы. Поэтому весь твой словесный понос выше, который ты навалил в попытках доказать то ли мне, то ли самому себе, что ты на самом деле крутой хакир - вызывает только жалость. Я надеюсь, что твой информационный пузырь и впредь будет оставаться таким же маленьким и непробиваемым, чтобы ты верил свои же словам, а не поехал кукухой к полтосу от горького осознания того, на какую же бесполезную туфту ты угробил свою единственную жизнь, при этом так и не дотянув профессионально даже до уровня двадцатилетней студетоты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #66

62. Сообщение от Аноним (72), 12-Авг-26, 06:08	+/–
> Да - аргумент против раста. Нет, "в вот если удалить" - это не аргумент для чего-либо. > Вы тыкаете растом как будто без него жить нельзя и всё сломается Нет, это твои фантазии: именно ТЫ запел и про "жить нельзя" и про то, что "все сломается", если зачем-то удалить существующий код. Я же нигде даже не намекал ни на что подобное, а Растом тыкаю в нос лицемера уже ПОСЛЕ того, как он сам первым начинает петь о Расте. > я показал что в ваших примерах раста изначально не было и они прекрасно работали без него. Насколько "прекрасно" они работали без него могут судить только те, кто их код разрабатывает и поддерживает, то есть уж точно не опеннетный Ванька. > Есть много ровестников раста решающих те же проблемы сходным образом Но ты тактично не назвал ни один. > он не проявил себя как хороший язык для разработки с нуля, это многие поняли на практике. И больше всех понял Ваня, который на Расте вообще не практикует. Кстати, а остальные "многие" сейчас с тобой в одной комнате? > Ещё лет 5 и появятся злые ненавистники которые будут рассказывать про ужасы рефакторинга легаси растокода. Целых пять лет еще ждать? Истории ужасов рефакторинга нарастающих десятилетиями C++-копролитов уже давно стали классикой, которую Расту будет трудно превзойти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #69

63. Сообщение от Антон (??), 12-Авг-26, 06:16	+/–
В свое время мне это тоже надоело и я решил потратить время на аккуратную реализацию своего костыля вдохновившись подходом системы сборки redo, но только вдохновившись. И это как мне кажется получилось. В итоге получилось очень точное отслеживание зависимостей, поддержка pkgconf, внешних проектов и много чего еще. Вот сайт проекта autark.dev
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #67

64. Сообщение от Аноним (64), 12-Авг-26, 07:28	+/–
Не вижу смысла в этих системах. Сейчас любой даже локальный qwen на видеокарте генерит с первого рабочие сборочные конфиги для make и cmake. Это область где нейрослоп заслужил право быть.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #68

65. Сообщение от пох. (?), 12-Авг-26, 11:59	+/–
> Есть cmake, но он у меня при сборке требует месона... его требует libux как там его, без которого в принципе собрать cmake можно но таким cmake может не получиться собрать что-то еще посложнее самого cmake. В общем, для сборки cmake нужен cmake. Я уже давно забил на эту поделку, и никогда сам ее с ее циклическими зависимостями даже не пытаюсь собирать. Отдельно она нежно мной любима за гвоздем прибитую версию в каждом файле, и отсутствие совместимости в принципе. automake, если не заставлять пользователя, которому он нахрен не нужен вообще, его каждый раз запускать - обходится почему-то вообще одним позикс-шеллом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #70

66. Сообщение от Ivan_83 (ok), 12-Авг-26, 12:52	+/–
Те технических аргументов не будет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

67. Сообщение от Ivan_83 (ok), 12-Авг-26, 13:41	+/–
Спс, прикольно сделано в плане генерации сборочного "скрипта" и самого синтаксиса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

68. Сообщение от Ivan_83 (ok), 12-Авг-26, 15:15	+/–
Так это вариант для джунов, когда код вроде знаешь как писать а со сборкой ничего не понятно. Я примерно так же взял автотул и нагуглил ритуалы для сборки своего кода, ваще ничо понятно не было. Но на постоянку то такое не вариант, особенно когда ты уже не студент и проект как бы только ради зачёта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #75

69. Сообщение от Ivan_83 (ok), 12-Авг-26, 15:18	+/–
Те аргументов в споре кроме "ты лицемер" и вот этого нейрослопа без технического содержания у вас нет? Я не понимаю причём тут наличие раста в продуктах которыми пользуются критики раста. При том, что большинство/почти все эти продукты раньше прекрасно обходились без раста. И могут дальше обойтись без раста - он не является какой то критической/значимой частью этих проектов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #73

70. Сообщение от Ivan_83 (ok), 12-Авг-26, 15:23	+1 +/–
Да, как то так. Те кто топит что cmake для сборки питон/месон не нужен - не видели бутстрапа на чистой системе :) У меня на работе продукт с нуля собирается, там прекрасно видно все эти грабли. Ещё для glib20 гномовской пришлось костылей наложить, там тоже либа сама от себя зависит %) Версии это отдельное, особо доставляющее, когда ты достаёшь проект которому лет 10 а там свежий цмейк начинает всякую ерунду писать :) Думаю он был неплохим, как и кресты в начале, потом в него понатащили всякого, включая скачивание и  работу с архивами и оно стало трудно поддерживаемым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #74

71. Сообщение от Ivan_83 (ok), 12-Авг-26, 15:25	–1 +/–
Это зависит не от pkg-conf а от того что написали в .pc файле авторы либы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #72

72. Сообщение от Аноним (72), 12-Авг-26, 15:31	+/–
> Это зависит не от pkg-conf а от того что написали в .pc файле авторы либы. Я буквально об этом и пишу: в pc-файле либы ты можешь написать ровно один набор флажков под конкретный компилятор. Даже в пределах одной системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

73. Сообщение от Аноним (72), 12-Авг-26, 15:36	+/–
> Те аргументов в споре кроме "ты лицемер" и вот этого нейрослопа без технического содержания у вас нет? Какая ирония: персонаж, только что фантазировавший про "а если удалить весь раст" запел про технические аргументы. > Я не понимаю причём тут наличие раста в продуктах которыми пользуются критики раста. Вот это и есть твоя проблема, Ваня - ты не понимаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #76

74. Сообщение от пох. (?), 12-Авг-26, 16:00	+/–
> Те кто топит что cmake для сборки питон/месон не нужен я когда-то пытался бороться, отключив половину фич. Их у него реально мильен, большая часть не нужна никому и о них и не знает никто. Но конкретно эту хрень уже не отключишь, или оно вообще собирать ничего не сможет. > Версии это отдельное, особо доставляющее, когда ты достаёшь проект которому лет 10 а там > свежий цмейк начинает всякую ерунду писать патамушта ни прямой ни обратной совместимости - "мы решили что с этой версии вон те все депрекейтед, и если вы хотите чтоб ваши проекты собирались не только свежайшим-из-под-хвоста - используйте другую сборочную систему".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #77

75. Сообщение от пох. (?), 12-Авг-26, 16:05	+/–
> Так это вариант для джунов, когда код вроде знаешь как писать а > со сборкой ничего не понятно. так тебе и говорят - нехрен париться, теперь даже qwen справляется. Собственно, я так и не научился разбираться в сложных cmake - нехай клава разбирается. Автотул изначально кстати был задуман под автоматическую генерацию. Т.е. предполагалось что ты можешь вообще не разбираться как он внутри устроен если не надо что-то специфическое, а просто запустить скрипт. Реализация как всегда подгуляла. Проще свой скрипт написать чем это настраивать. > Но на постоянку то такое не вариант, особенно когда ты уже не > студент и проект как бы только ради зачёта. теперь - вариант. Именно потому что не студент и всем пофигу чем ты там нагенерил мэйкфайлы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #80

76. Сообщение от Ivan_83 (ok), 12-Авг-26, 16:18	+/–
А раз вы не можете объяснить свою позицию то дальнейший спор не возможен :) Удалить весь раст - технически возможно, доказательство тому - он ещё не так давно везде отсутствовал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

77. Сообщение от Ivan_83 (ok), 12-Авг-26, 16:21	+/–
В нашем случае меня сильно тригерит что ccache собирается cmake, как итог у нас мимо ccache собирается много всего, и самое тяжёлое это питон, перл и cmake. Но я тут же накидал chroot_env который умеет с базовой системы втягивать нужное, но боюсь что у нас будут конфликты как раз в зависимостях самого ccache между хостом и chroot в котором собирается...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #78

78. Сообщение от пох. (?), 12-Авг-26, 16:30	+/–
он же вроде после сборки ни от чего уже особо не зависит? (сто лет было не надо)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #79

79. Сообщение от Ivan_83 (ok), 12-Авг-26, 19:19	+/–
libfmt, libzstd, libxxhash и вроде что то ещё было. Можно собрать статикой, но надо проверять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

80. Сообщение от Ivan_83 (ok), 12-Авг-26, 19:22	+/–
Вопрос отношения. Сделать то можно, но потом такое может оказатся неподдерживаемым или там заведётся нечто неожиданное :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

81. Сообщение от Аноним (81), 12-Авг-26, 22:54	+/–
>Код Meson написан на языке Python Если не те autotools, ты берёшь те autotools. И оно работает. Если с Meson проблемы, придётся брать Python. А тот уже на Autotools. Наглядно - вся нужность сборочного инструментария. Могли бы сделать правильно - вшить внутрь какой-нибудь Lua или тот диалект Scheme из Mes. Но нет, им нужен Python, в котором всё равно ни один рандомный питонист разбираться не будет.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема