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

"Релиз сборочной системы CMake 4.1.0 "	+/–
Сообщение от opennews (??), 12-Авг-25, 10:34
Представлен релиз кроссплатформенного открытого генератора сценариев сборки CMake 4.1.0, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63713
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 12-Авг-25, 10:34	+22 +/–
В каком интересно месте он "простой языка сценариев"? По-моему он давно примкнул к тем кого должен был заменить
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #4

2. Сообщение от Аноним (2), 12-Авг-25, 10:38	+8 +/–
Тоже обратил внимание, что все альтернативы старому-доброму make почему-то сложнее и только продолжают бухнуть. Может конечно возможность выкачивать зависимости с гитхаба напрямую и есть хорошо, но вот эта вечная беготня с «да что перестроить уже, чтобы ты готовую либу всё же увидел» и жонглированием трудночитаемыми конфигами напрягает. А сколько дыр через все эти навороченные системы сборки пролезает...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3, #5, #11, #13

3. Сообщение от IMBird (ok), 12-Авг-25, 10:39	+9 +/–
Крепитесь: всё чаще попадаются C/C++ проекты со сборочными скриптами на питоне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7, #8, #14, #120

4. Сообщение от Аноним (7), 12-Авг-25, 10:41	+/–
А где ты там сложности вообще увидел? target_link_libraries не осилил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #34

5. Сообщение от Аноним (7), 12-Авг-25, 10:43	+1 +/–
>все альтернативы старому-доброму make Я тебе маленький секрет открою. На выходе cmake генерится старый добрый Makefile.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #12, #16, #33, #36, #50

6. Сообщение от Жироватт (ok), 12-Авг-25, 10:43	+3 +/–
Интересно, как скоро а) язык конфигурирования сборочной системы СМаке оформится как отдельный, полноценнный Тьюринг-полный язык, б) для которого нужен будет свой язык конфигурирования сборки?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #79

7. Сообщение от Аноним (7), 12-Авг-25, 10:46	+/–
Так питон идеальный язык для быстрого написания скриптов. Разве не так? И да, meson открой для себя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #10, #15, #122, #123

8. Сообщение от Аноним (2), 12-Авг-25, 10:46	+1 +/–
А почему не на расте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #24

10. Сообщение от Аноним (2), 12-Авг-25, 10:48	+2 +/–
На мезоне сидят гтк, вяленд, системд и оригинальный ксорг, что как бы намекает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #59

11. Сообщение от Аноним (12), 12-Авг-25, 10:53	+1 +/–
> Тоже обратил внимание, что все альтернативы старому-доброму make А make когда-то был системой сборки? 😂
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #78, #143

12. Сообщение от Аноним (12), 12-Авг-25, 11:03	+7 +/–
Да он CMake и не пользуется. И наверняка вообще имеет условное отношение к разработке на C или C++, ибо собирать сколь-нибудь большой проект на этих языках при помощи голого make - это чистый мазохизм. Коллеги тебе этого тупо не дадут сделать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #26

13. Сообщение от Аноним (13), 12-Авг-25, 11:04	–2 +/–
А не что тот факт, что cmake - это генератор Makefile'ов, т.е. аналог autotools. Makefile, cгенерированный cmake'ом, затем внезапно запускается в обычном make.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #18, #86

14. Сообщение от анонд (?), 12-Авг-25, 11:14	+/–
и Lua (xmake с xrepo в китайских проектах) Питон это Meson или Conan
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #62, #124

15. Сообщение от анонд (?), 12-Авг-25, 11:15	+/–
Версии сборочных системы не всегда совместимы как тотже Conan (1.x vs 2.x) в отличие от CMake
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

16. Сообщение от анонд (?), 12-Авг-25, 11:16	+/–
CMake использует Ninja (когда доступно)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

17. Сообщение от anon57 (?), 12-Авг-25, 11:16	+2 +/–
На работе, в основных проектах, был выбран CMake. Периодически приходиться нырять в эту чертовщину и чинить. Хорошо хоть появились форки CMake с поддержкой отладки. Для домашних проектов использую premake5. С версии 5-beta6 появился API для управления зависимостями примерно как в CMake. Теперь можно описать как использовать либу, а потом просто воткнуть в проекте uses 'SDL3' и нужные опции прокидываются. Тут если что почитать можно: https://premake.github.io/docs/Usages-and-Uses Короче CMake не нужен, закапывайте.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #42

18. Сообщение от анонд (?), 12-Авг-25, 11:17	+2 +/–
CMake поддерживает несколько генераторов. Ninja намного производительнее чем Make
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #29

19. Сообщение от анонд (?), 12-Авг-25, 11:18	+2 +/–
Все используют CMake, но писать на этом языке никто не хочет
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

21. Сообщение от Аноним (21), 12-Авг-25, 11:30	+1 +/–
так CMake уже Тьюринг-полный и скрипты можно запускать не в режиме сборки, а в режиме интерпретации через ключ -P
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

22. Сообщение от Аноним (22), 12-Авг-25, 12:08	+3 +/–
Беда почти всех яп - чтобы собрать программу, надо выучить ещё один язык. Хорошо, что я сборщики себе на сях свои пишу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #32, #47

23. Сообщение от Аноним (23), 12-Авг-25, 12:14	–1 +/–
что мешает писать все в одном файле? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #25

24. Сообщение от Аноним (24), 12-Авг-25, 12:14	+1 +/–
> А почему не на расте? Угадай с трех раз, на чем пишутся сборочные скрипты для проектов на расте ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #30

25. Сообщение от Аноним (-), 12-Авг-25, 12:42	–1 +/–
Нужно умещать весь код в один экран, как это делает создатель языка K.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #38

26. Сообщение от Аноним (26), 12-Авг-25, 12:45	–2 +/–
Эти коллеги в вкусно-и-точка скоро работать уйдут, т.к. иишка всех лоускилов выкидывает уже с рынка. Я вот стартап пилю и там только Make, т.к. это мегаудобно все вспомогательные действия держать в 1 месте а не плодить кучу мелких скриптов. И действия - любые, а не только предусмотренные авторами смаке. И качать зависимости можно хоть с гитхуба хоть откуда прозрачным способом и билдить их какой угодно сторонней системой сборки, просто сделав соответсвующий таргет. При этом собственно сборка всех с/с++ файлов проекта - 7 строк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #28

27. Сообщение от Аноним (12), 12-Авг-25, 12:49	+1 +/–
> С версии 5-beta6 появился API для управления зависимостями примерно как в CMake. > нужные опции прокидываются > Короче CMake не нужен, закапывайте То есть недавно в бета-версии premake появилась опция, которая доступна в CMake уже лет 20? Уже бегу закапывать CMake!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

28. Сообщение от Аноним (12), 12-Авг-25, 13:00	+/–
> Эти коллеги в вкусно-и-точка скоро работать уйдут > Я вот стартап пилю Ну, то есть, на мороз пока выкинули только тебя. 😂 Стартап, лол... > все вспомогательные действия держать в 1 месте а не плодить кучу мелких скриптов И весь исходный код тоже в одном файле, надеюсь? 😂 Хотя, когда у тебя хэллоуворлд - это не проблема, так ведь? > И действия - любые, а не только предусмотренные авторами смаке А, ну понятно: еще один эксперт, который CMake в глаза не видел, рассказывает об его ограничениях. 🤦 > И качать зависимости можно хоть с гитхуба хоть откуда прозрачным способом и билдить их какой угодно сторонней системой сборки, просто сделав соответсвующий таргет. При этом собственно сборка всех с/с++ файлов проекта - 7 строк. Ты не поверишь, но в CMake тоже так 🤯. Только вот работать оно будет на всех системах (даже Винде), а не только в юниксовом окружении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31

29. Сообщение от Аноним (26), 12-Авг-25, 13:06	–4 +/–
> Ninja намного производительнее чем Make Это миф. Ninja просто запускает подготовленные кем-то (basel например) команды из compile_commands.json. 1. если в makefile просто засунуть список этих команд, без вычисления зависимостей, то отработает за +- то же время, но так люди не делают, т.к. не читаемо. 2. ninja отрабатывает после генератора этого compile_commands.json и если сложить время, то оно будет больше чем у нормального человеческого Makefile из нескольких строчек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #35, #39

30. Сообщение от Советский инженер (ok), 12-Авг-25, 13:12	+3 +/–
что там гадать. toml & rust (build.rs)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

31. Сообщение от Аноним (26), 12-Авг-25, 13:13	–4 +/–
Ну каг бе стратап зарабатывает уже неплохо, есть некоторый штат сотрудников, а я за CTO. Я заранее подготовился, а кого-то вот ждёт неприятный сюрприз. Кусочки кода, которые узко смотрящие кодеры могут писать, давно уже нейронка делает. > эксперт, который CMake в глаза не видел 15 лет в IT за деньги, а так ещё больше. > даже Винде А мне не надо чтобы на венде работало (но там вообще-то есть линукс окружение и собрать можно если не лоускил или хотя бы дипсик осилил).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #37

32. Сообщение от trolleybus (?), 12-Авг-25, 13:14	+/–
Rust с build.rs нервно курит в сторонке... Хотя, о чем это я. Для экспертов опеннета раст - не язык.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #51

33. Сообщение от Советский инженер (ok), 12-Авг-25, 13:17	+1 +/–
я тебе маленький секрет открою. СMake никогда не был альтернативой make. СMake стартанул как альтернатива autotools.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

34. Сообщение от Аноним (34), 12-Авг-25, 13:19	+2 +/–
В прошлый раз тут советовали писать тесты для оператора if, потому что по меркам CMake это сложная логика с проблемным легаси ("The if command was written very early in CMake's history..."), которое решили не чинить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #41

35. Сообщение от Советский инженер (ok), 12-Авг-25, 13:20	+5 +/–
> ... команды из compile_commands.json 🤣🤣🤣
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

36. Сообщение от Аноним (36), 12-Авг-25, 13:21	+/–
Согласен cmake ./ make
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

37. Сообщение от Аноним (12), 12-Авг-25, 13:24	+2 +/–
> есть некоторый штат сотрудников, а я за CTO Ты уж определись, СТО ты или кодер-писатель make. 😂 > 15 лет в IT за деньги, а так ещё больше Жаль, что не на позиции разработчика. 😂 А то в любом серьезном проекте ты за ручное написание make получил бы по шапке уже в первый месяц. 🤣 > А мне не надо чтобы на венде работало Да я и не сомневался. Только вот тем, кому это надо - используют CMake. > но там вообще-то есть линукс окружение и собрать можно если не лоускил или хотя бы дипсик осилил Тебе об этом тот самый Дипсик сказал? Спроси его заодно, зачем мне там на Винде "линукс окружение", если проект собирается с msvc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #44, #69

38. Сообщение от Аноним (23), 12-Авг-25, 13:25	+1 +/–
забыл совсем, у вас там скрол не работает в терминале :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

39. Сообщение от Аноним (12), 12-Авг-25, 13:30	+3 +/–
>> Ninja намного производительнее чем Make > Это миф. Ninja просто запускает подготовленные кем-то (basel например) команды из compile_commands.json. Вот такие вот истории со срывами покровов получаются, когда стартапного СТО познакомить с DeepSeek... 🤦
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #40

40. Сообщение от Аноним (26), 12-Авг-25, 13:41	–2 +/–
Чатик мне запилил так-то рабочий скрипт для конвертации мезон либ в тупо папку в проекте с исходниками парсингом compile_commands.json, так что я в курсе, как это работает. Makefile в отличие от cmake не требует указывать каждый C/C++ файл (тот так может но криво и ломается так сборка постоянно, поэтому у смачников сизифов труд по добавлению каждого с файла в смаке). Т.к. мне не нужно иметь кучу раздутых so всё собирается статически с едиными флагами в компактный бинарь. И да, я использую генерацию кода - и что вы мне сделаете) Раздутый штат кодеров больше компаниям не нужон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #48

41. Сообщение от Аноним (7), 12-Авг-25, 13:43	+1 +/–
Не знаю, кто там тебе и чего советовал, но проект на cmake накинуть можно за пару минут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

42. Сообщение от Аноним (7), 12-Авг-25, 13:44	+2 +/–
>в основных проектах >нырять в эту чертовщину и чинить Наверное тут надо команду разработи менять, а не cmake.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #58, #93

43. Сообщение от Аноним (7), 12-Авг-25, 13:48	+/–
Я тебя может удивлю, но пользователи cmake даже не используют. Только мейнтейнеры и изредка программисты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

44. Сообщение от Аноним (26), 12-Авг-25, 13:58	+/–
> Ты уж определись, СТО ты или кодер-писатель make. Тут некоторые жалуются мол синтаксис непонятный. Чатик всё напишет если что-то нетривиальное нужно. Лычку мастера мейкфайлов иметь не обязательно, достаточно иметь положительный iq. А так я много чё делаю, RnD всякое, деплой, настройка системы, оптимизация нейросетевых моделек - не только код пишу. Поэтому make как инструмент автоматизации не только лишь сборки - мастхэв. > если проект собирается с msvc Кто в здравом уме в 2к25 будет планировать стартап под венду? Либо под мак писать надо, т.к. деньги там, либо веб, котороый на линукс / wasm кругом, либо хардварный стартап с прошивками - там опять же msvc ненужон. Везде Make как родной. Если игру делать - то они все на готовых движках со своими билд системами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #70, #138

45. Сообщение от Аноним (45), 12-Авг-25, 14:02	+/–
Кто-нибудь пробовал системы сборки meson или bazel?
Ответить | Правка | Наверх | Cообщить модератору

46. Сообщение от Аноним (45), 12-Авг-25, 14:08	+/–
Зависимости cmake весят больше программы в несколько раз. Прикольно, че.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #56, #96, #107, #145

47. Сообщение от Аноним (47), 12-Авг-25, 14:10	+/–
а в чем проблема писать так чтобы одного языка хватало?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #81

48. Сообщение от Аноним (12), 12-Авг-25, 14:13	+2 +/–
> рабочий скрипт для конвертации мезон либ в тупо папку в проекте с исходниками парсингом compile_commands.json Попроси чатик объяснит смысл этого набора случайных слов, ибо я лично распарсить его не смог. > Makefile в отличие от cmake не требует указывать каждый C/C++ фай CMake тоже не требует. Спроси у своего чатика о CONFIGURE_DEPENDS. > Т.к. мне не нужно иметь кучу раздутых so всё собирается статически с едиными флагами Ага, все сторонние либы, да еще и C с C++ вперемешку - с едиными флагами? 😂 Ну сказано же: мастер хэллоуворлдов, реальных кодовых баз в глаза не видавший. > И да, я использую генерацию кода - и что вы мне сделаете) Проявим сочувствие. Ну, насколько это возможно к "стартапному СЕО, по совместительству писателю мейкфайлов при помощи DeepSeek" 🤣
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #49

49. Сообщение от Аноним (26), 12-Авг-25, 14:24	–3 +/–
> я лично распарсить его не смог Не мудрено для i shaped специалиста по смаке. Поясняю - берётся мезон либа, указываются нужные флаги, мезон генерит compile_commands, скипт на питоне достаёт оттуда пути к собираемым файлам, фиксит корявые пути к инклудам и кладёт с/с++/h файлы в отдельную папочку внутри Makefile проекта. Всё, больше мезон не нужен. > C с C++ вперемешку - с едиными флагами? Да, прикинь? Проект на C/C++ с едиными флагами (кроме версии стандарта языка разве что, это включено в CC/CXX переменную) app: $(patsubst %.cpp,build/%.cpp.o,$(SRC_CPP)) $(patsubst %.c,build/%.c.o,$(SRC_C))     $(CXX) $^ $(LFLAGS) -o app build/%.c.o: %.c     $(CC) $(CFLAGS) -I$(dir $<) -MD -c $< -o $@ build/%.cpp.o: %.cpp     $(CXX) $(CFLAGS) -I$(dir $<) -MD -c $< -o $@ -include $(patsubst %.cpp,build/%.d,$(SRC_CPP)) $(patsubst %.c,build/%.d,$(SRC_C)) И всё! Надо будет - добавлю go / swift / что угодно компилируемое. > Проявим сочувствие Учитесь, пока не поздно) Либо правильному промптингу нейронок, либо котлету на булку класть)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #53, #65, #111

50. Сообщение от Аноним (50), 12-Авг-25, 14:31	+/–
Давно уже генерится ninja. Потому что make не умеет не только в конфигурацию проекта, но и в собственно сборку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #61

51. Сообщение от Аноним (50), 12-Авг-25, 14:34	+/–
build.rs нужен в одном крейте из ста. Для обычной сборки обычного проекта на rust (с зависимостями, естественно) вообще ни строчки сборочной системы написать не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

52. Сообщение от нах. (?), 12-Авг-25, 14:42	+/–
смешнее то что куча из них (к счастью, не все - обязательные) давно сами без cmake не собираются. (поэтому у вас и не будет больше ни одной нормальной ос после линукса и венды)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #54, #57

53. Сообщение от Аноним (12), 12-Авг-25, 14:52	+1 +/–
> Поясняю - берётся мезон либа, указываются нужные флаги, мезон генерит compile_commands, скипт на питоне достаёт оттуда пути к собираемым файлам, фиксит корявые пути к инклудам и кладёт с/с++/h файлы в отдельную папочку внутри Makefile проекта. Всё, больше мезон не нужен. Т.е. из человеческого, поддерживаемого Meson файла ты сделал write-only портянку make на выброс, с прибитыми гвоздями инклюдами и по пути угрохав даже *внутренние для либы* флаги компиляции? 😂 Не, ну это гениально! Вот оно - последствие влияния нейронок на неокрепшие умы вайтишников. Вайб-кодерам хоть простительно - они в код не смотрят, а тут... > Да, прикинь? Проект на C/C++ с едиными флагами (кроме версии стандарта языка разве что, это включено в CC/CXX переменную) "Прикинь 😧" у тебя будет, когда ты прекратишь сочинять находу и действительно попробуешь таким подходом скомпилировать что-то больше своего хэллоуворлда. И в тот же самый момент до тебя дойдет, зачем нужны билд-системы. даже в пределах одного окружения. > I$(dir $<) -MD -c $< -o $@ > И всё! Апхапхах! "И все!" А эти все глупцы десятилетиями Автомейки с Симейками зачем-то придумывают. Узрите, несчастные, как стартапный СТО заменил все ваши поделия одним заклинанием make!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #67

54. Сообщение от Аноним (54), 12-Авг-25, 15:06	+1 +/–
Ну GCC вот тоже без GCC не собирается, и что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #60, #64, #77

56. Сообщение от НеФанат (?), 12-Авг-25, 15:08	–1 +/–
Используй для таких программ обычный make Смотри: https://www.opennet.me/openforum/vsluhforumID3/137560.html#49
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #112

57. Сообщение от Аноним (45), 12-Авг-25, 15:15	+/–
"Это какой-то позор..." (с)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

58. Сообщение от Аноним (12), 12-Авг-25, 15:15	+3 +/–
> Наверное тут надо команду разработи менять, а не cmake. Упонминание в комментарии "uses 'SDL3'" говорит о том, что "комнда" состоит лишь из него самого, пишущего для себя игрушки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

59. Сообщение от ryoken (ok), 12-Авг-25, 15:16	+/–
У мну в генте по-моему все эти сборочные системы есть. Точно видел cmake, meson, ninja ,%SUBJ% и может еще кого-то. Но особо внимания не обращал, т.к. после запуска  emerge @world обычно иду спать :).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

60. Сообщение от Аноним (12), 12-Авг-25, 15:17	+/–
А это очень неудобный вопрос!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #63

61. Сообщение от Аноним (61), 12-Авг-25, 15:18	–1 +/–
Мне make не нравится своими тонкостями, которые необходимо помнить. Но вот что бы он в сборку не умел. Я чего то не знаю - получается. Что за проблемы у make со сборкой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

62. Сообщение от IMBird (ok), 12-Авг-25, 15:18	+2 +/–
Большое спасибо, я посмотрел и проникся. Даже FPC поддерживает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #135

63. Сообщение от Аноним (23), 12-Авг-25, 15:28	+/–
Там вопрос не сформируется - рекурсия бесконечная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

64. Сообщение от нах. (?), 12-Авг-25, 15:28	+1 +/–
вообще-то до недавнего времени собирался - причем чем-то уровня чуть ли не tinyc. Если даже поломали - ты все еще можешь им собрать 2.7.2 и последовательно доапгрейдиться до какой там тебе нужен для хеловротов. Именно благодаря этому у нас есть линукс. Потому что кросскомпилятором ты бы до сих пор что-то вроде хурда собирал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #71, #72

65. Сообщение от нах. (?), 12-Авг-25, 15:33	+/–
> build/%.c.o: %.c ну сразу приехали. Ты просохатил зависимости от .h Про то что это фу-фу-фу gnu make only уж не будем (этот, хотя бы, все еще собирается в любой  мыслимой и части немыслимых сред, где хотя бы есть posix shell и не очень безнадежно старый gcc) то есть для одноразовой поделки прокатит, для своего проекта уже непригодно сходу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #68

66. Сообщение от Аноним (-), 12-Авг-25, 15:36	+/–
Автор забыл упомянуть, что CMake - это инструмент для тех, кто программирует на C++.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #106

67. Сообщение от Аноним (67), 12-Авг-25, 15:50	+/–
> Т.е. из человеческого, поддерживаемого Meson файла Наоборот же мезон мне поддерживать не нужно а либу нужно было допилить поэтому удобнее всё в единой системе сборки держать. Пересобирать либу снаружи проекта через мезон и дольше и неудобнее чем используя инкрементальную пересборку Make проекта. > прибитыми гвоздями инклюдами А инклюды как раз из хрен пойми каких путей преобразуются просто в путь к папке этой либы в проекте как и для всех остальных модулей. Поэтому инклуды разных модулей мне не нужно указывать в общих флагах. > write-only портянку make на выброс 7 строк всего для сборки C/C++, переиспользую из проекта в проект. Типичная мезон/смаке портянка куда больше т.к. в смаке каждый исходный файл проекта перечисляют. > стартапный СТО Сам-то чего добился ?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

68. Сообщение от Аноним (67), 12-Авг-25, 15:53	+/–
Нет они учтены в -include $(patsubst %.cpp,build/%.d,$(SRC_CPP)) $(patsubst %.c,build/%.d,$(SRC_C))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #85

69. Сообщение от Аноним (70), 12-Авг-25, 15:55	+/–
>за ручное написание make получил бы по шапке уже в первый месяц А разве уже не достаточно? cmake cmake --build cmake --install
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

70. Сообщение от Аноним (70), 12-Авг-25, 15:55	+/–
>Если игру делать - то они все на готовых движках со своими билд системами. Не знаю, у меня что сборка исходников, что уровней, что моделей, всё в батниках с компиляторами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

71. Сообщение от Аноним (54), 12-Авг-25, 16:00	+/–
> Если даже поломали - ты все еще можешь им собрать 2.7.2 и последовательно доапгрейдиться до какой там тебе нужен для хеловротов. Полагаю, с CMake можно поступить так же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #84

72. Сообщение от Аноним (12), 12-Авг-25, 16:31	+/–
> вообще-то до недавнего времени собирался - причем чем-то уровня чуть ли не tinyc Лол, какой еще tinyc? 😂 С версии 4.8 (2013 год) GCC написан на C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #82

73. Сообщение от nc (ok), 12-Авг-25, 16:39	–1 +/–
Для винды пользуюсь штатными *.vcxproj Студии и всё устраивает. Для линукса пользуюсь штатными *.pro QtCreator'а и всё устраивает. Все эти сборочные скрипты (make, cmake и т.п., тысячи их)... ни разу в жизни не понадобились, исключая только компиляцию исходников скачанных из инета. И то нередко такое бывает что скачаешь, а оно не компилируется.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #75, #94, #101, #108, #133

75. Сообщение от Аноним (12), 12-Авг-25, 16:59	+1 +/–
> Для винды пользуюсь штатными *.vcxproj Студии и всё устраивает. > Для линукса пользуюсь штатными *.pro QtCreator'а и всё устраивает. Ну а мог бы один раз под обе платформы написать CMkae файл. Ну и да, под Линуксом и Маком далеко не все проекты юзают QtCreator (именно для сборки). > Все эти сборочные скрипты (make, cmake и т.п., тысячи их)... ни разу в жизни не понадобились Это ровно до того момента, когда сборка проекта подразумевает что-то помимо компиляции C++ кода (т.е. когда у проекта кроме исполняемого есть и другие файлы). Вот тут на помощь как раз и приходят CMake и подобные, которые позволяют написать *всю* логику сборки один раз и под все платформы. Да, это логика все равно на опеределенный процент может быть специфичной для платформы, но главное что оставшаяся большая часть не дублируется в двух разных ".sh", ".bat" и т.п., да и сам "скрипт" является частью системы (и процесса) сборки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

77. Сообщение от Аноним (77), 12-Авг-25, 17:12	+/–
даже больше, современному gcc нужен питон
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #83

78. Сообщение от _ (??), 12-Авг-25, 17:29	+1 +/–
А что - когда то не был? O'Riley :-? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

79. Сообщение от Аноним (79), 12-Авг-25, 17:47	–1 +/–
а) уже б) Bazel. Нормальный высокоуровневый почти-пайтон, который CMake может генерить. Мы используем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

81. Сообщение от _ (??), 12-Авг-25, 17:49	+/–
В том что одного не хватает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

82. Сообщение от нах. (?), 12-Авг-25, 17:51	+/–
значит, соберешь сперва 4.7 (Если тебе прям уперлось для твоей болгеносы наираспоследнюю версию компилятора) это всяко попроще чем пытаться портировать наираспоследний компилятор на ос в которой еще ничего нет потому что нет компилятора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

83. Сообщение от нах. (?), 12-Авг-25, 17:53	+/–
> даже больше, современному gcc нужен питон ну я собственно и говорил - повторить линукс не получится. Потому что "нужен пихон" а потом по зависимостям еще и хруст приедет. Со всеми тремя своими поддерживаемыми платформами - виндой, виндой, и еще, вот...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #113

84. Сообщение от нах. (?), 12-Авг-25, 17:56	+/–
>> Если даже поломали - ты все еще можешь им собрать 2.7.2 и последовательно доапгрейдиться до какой там тебе нужен для хеловротов. > Полагаю, с CMake можно поступить так же. нет, конечно. Потому что мильен зависимостей и пяток из них сами требуют cmake. Причем гвоздем прибита конкретная наираспоследняя версия (обычно если ее понизить этак на пяток ничего не ломается, но мы про новую ос а не портирование на freebsd7)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #89, #98

85. Сообщение от нах. (?), 12-Авг-25, 17:58	+/–
> Нет они учтены в -include $(patsubst %.cpp,build/%.d И кто вот это всьо генерить должен - руками каждый .h добавляешь, что-ли? make dep не просто так был придуман в auto* подходе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #88

86. Сообщение от нах. (?), 12-Авг-25, 18:02	–5 +/–
> А не что тот факт, что cmake - это генератор Makefile'ов, т.е. > аналог autotools. ни разу не, потому что autotools - генератор _генератора_ мэйкфалов. > Makefile, cгенерированный cmake'ом, затем внезапно запускается в обычном > make. но только на той системе и только в той единственной конфигурации где был произведен. А configure сгенерит тебе мэйкфайлы на ЛЮБОЙ поддерживаемой системе, с учетом твоих личных пожеланий. БЕЗ autotools. Они нужны только автору. И то не каждый день. Просто выросло поколение не умеющих ими пользоваться и не понимающее зачем оно вообще надо. (ни разу не для генерации мэйкфайлов было задумано)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #91, #92, #132

88. Сообщение от Аноним (26), 12-Авг-25, 18:15	+/–
GCC сам же и генерит d файлы, в которых в понятном мейку виде лежат зависимости от h файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

89. Сообщение от Аноним (54), 12-Авг-25, 18:25	+/–
Так начиная со старой же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

90. Сообщение от Аноним (90), 12-Авг-25, 18:28	–2 +/–
Никогда не понимал тех, кто билдит под линух и избегает мейк, если проект по сложности не ядро, то использование чего-то отличного от классического мейка неоправдано. Это банальное неуважение к тем, кто возможно будет работать над такими проктами - порой доходит до абсурда - проект по сложности хеловрот какой нибудь, однако уже сборочного мусора натащено немало.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #97, #104

91. Сообщение от Аноним (91), 12-Авг-25, 18:40	+3 +/–
>> Makefile, cгенерированный cmake'ом, затем внезапно запускается в обычном make. > но только на той системе и только в той единственной конфигурации где был произведен. Ну да, в этом весь смысл. Кроссплатформенным инструментом является cmake, а не его выхлоп. Или ты хочешь  сказать, что в сценарии: > configure сгенерит тебе мэйкфайлы на ЛЮБОЙ поддерживаемой системе ...получившийся Makefile будет работать не "только на той системе и только в той единственной конфигурации где был произведен"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #146

92. Сообщение от Аноним (91), 12-Авг-25, 18:46	+2 +/–
> Просто выросло поколение не умеющих ими пользоваться и не понимающее зачем оно вообще надо Так а действительно: зачем вообще надо использовать древний копролит из нагромождения Shell, Perl и M4, намертво прибитый к Unix-окружению и применяющийся сугубо в опенсорсном легаси?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

93. Сообщение от Аноним (93), 12-Авг-25, 18:59	–1 +/–
явно ничего сложнее на cmake чем хелоу ворд не делал, cmake когда тянешь кучу blas, mkl или прочего сразу затыкается, т. к. или везде разные версии cmake саморезами прикручены или вручную каждую библиотеку в path прописывать, отлаживать эту подделку псевдоязыкописателей сложно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #95

94. Сообщение от Советский инженер (ok), 12-Авг-25, 19:00	+/–
> ... пользуюсь штатными *.pro QtCreator'а есть огромный шанс что в Qt 7 максимум 8 никакого *.pro не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #99

95. Сообщение от Аноним (91), 12-Авг-25, 19:31	+/–
> cmake когда тянешь кучу blas, mkl или прочего сразу затыкается, т. к. или везде разные версии cmake саморезами прикручены У cmake есть обратная совместимость, поэтому просто берешь ту его версию, которая равна или новее всех версий, требуемых твоими библиотеками. А вот, например, в репе Debian аж 3 версии autoconf (2.13, 2.64 и 2.69). Догадываешься, почему? 😂
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #115

96. Сообщение от Аноним (91), 12-Авг-25, 19:32	+1 +/–
> Зависимости cmake весят больше программы в несколько раз. А кому-то не плевать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

97. Сообщение от Аноним (91), 12-Авг-25, 19:38	+/–
> использование чего-то отличного от классического мейка неоправдано. Как ты для себя объясняешь наличие Autotools? > Это банальное неуважение к тем, кто возможно будет работать над такими проктами - порой доходит до абсурда Пример того самого абсурда: > In 1991, David J. MacKenzie got tired of customizing Makefile for the 20 platforms he had to deal with. https://www.gnu.org/software/automake/manual/html_node/GNU-B...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #109, #117

98. Сообщение от Аноним (50), 12-Авг-25, 19:41	–1 +/–
> нет, конечно. Потому что мильен зависимостей и пяток из них сами требуют cmake Зависимостей пяток (expat, idn2, jsoncpp, rhash, uv, curses, openssl) и ни одна из них не требует cmake. Лол, ты как обычно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

99. Сообщение от Аноним (50), 12-Авг-25, 19:43	+1 +/–
qmake deprecated уже в Qt6.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #141

101. Сообщение от Аноним (101), 12-Авг-25, 19:54	+1 +/–
В CI/CD тоже студию и креатор запускаешь? Или у вас всё по-семейному, резилы делает дед на своём лаптопе и закачивает по FTP?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #121

104. Сообщение от Аноним (50), 12-Авг-25, 20:23	+/–
Наоборот, неуважение - это использовать убогий по возможностям, и при этом неоправданно переусложнённый (чтобы сделать правильно) make. Перечислю (что вспомню) что обычно приходится править в мейкфайлах таких вот "непонимающих", чтобы собрать или опакетить среднестатистический проект на make: - `all` цель, её обычно нет. - Прямые вызовы `gcc` типа `gcc -o foo foo.c`. У меня в системе нет `gcc`. Нужно `${CC}` - Присвоение переменных без переопределения типа `CC=gcc`. Нужно `CC?=gcc`, `CC` передаётся через окружение. - Отсутствие флагов. не `${CC} -o foo foo.c`, а `${CC} ${CFLAGS} -o foo foo.c`. - `CFLAGS=` вместо `CFLAGS?=` и `CFLAGS+=`, аналогично `CC`. - Системные флаги не под `CFLAGS?=` и проекто-специфичные не под `CFLAGS+=`. Например, `-O3 -march=native` это системные флаги, можете по полной некомпетентности использовать такие как умолчание, но они должны переопределяться локальными `CFLAGS` из окружения. А `-Wall` это проекто-специфичный флаг, он должен _добавляться_, при этом безусловно. - Использование `-march=native` в любом виде. С ним соберётся непереносимый, суть битый пакет/бинарник. - Использование `-Werror` в любом виде. Вне твоего локалхоста варнинги _всегда будут_. Нет, я не собираюсь их тебе исправлять. - `LDFLAGS` - аналогично `CFLAGS` - Вызов сабмейка как make, вместо `${MAKE}`. У меня в системе `make` не то что ты думаешь. - Добавление библиотек через `-l` вместо `pkg-config --libs` (хотя и то и то неправильно; правильно - как делает cmake, добавляет полный путь к библиотекам`) - Добавление путей к инклудам зависимостей через `-I` вместо `-isystem`. - Добавление путей к инклудам зависимостей через `-I`/`-isystem` вместо `pkg-config`. Ты не знаешь путей на моей системе, `pkg-config` знает. Этот пункт противоречит предыдущему потому что `pkg-config` обычно отдаёт `-I` вместо `-isystem`. Это одна из причин почему на make нельзя сделать правильно работающую сборку. - Пути к системным инклудам до своих (частично решается `-isystem`). - Любые захардкоженные абсолютные пути, включая `/usr/local` - Установка не в ${PREFIX}. - Установка не в ${DESTDIR}. - Попадание ${DESTDIR} в бинарник. Оно имеет смысл только при установке. - Любые непортабельные флаги для `install` типа `-D`. - Установка в нестандартные директории типа `${PREFIX}/games/bin` или `${PREFIX}/lib64`. На самом деле, установка по любым захардкоженным путям. Правильно - cmake'вский `GNUInstallDirs` - Извращения с вызовом git чтобы узнать версию проекта из тэга. Хотя вообще этим и из cmake грешат. Прикинь, твой проект скачан архивом, а .git есть в корне, и ты берёшь версию оттуда. - Про поддержку кросскомпиляции даже заикаться не буду. Справедливости ради, её и cmake не умеет. Ну и не буду даже упоминать такие банальные вещи как то что make не умеет в нормальную параллельную сборку, даже cmake и meson генерят ninja файлы. И не умеет генерацию ide проектов что абсолютно обязательно для системы сборки. Ну и на звёздочку - настоящий переносимый Makefile должен поддерживать gnu и bsd диалекты. Удачи с этим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #110, #118, #127, #129, #148

106. Сообщение от 12yoexpert (ok), 12-Авг-25, 20:30	+1 +/–
и в принципе единственный вариант для тех, кто пишет десктопный софт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

107. Сообщение от Аноним (50), 12-Авг-25, 20:30	+1 +/–
Компилятор тоже больше программы в несколько раз, и чо? Так-то недалёкие неосиляторы cmake этот же аргумент использовали даже во времена autocrap, когда "больше программы в несколько раз" был не единственный cmake на систему (с горсткой зависимостей, используемых кучей других программ), а простыня блевотного configure которая шла в каждом проекте и никому кроме него не была нужна. Т.е. десяток мегабайт cmake это у них много, а сотня configure на мегабайт каждый, это фигня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

108. Сообщение от 12yoexpert (ok), 12-Авг-25, 20:31	+/–
> Для винды пользуюсь штатными *.vcxproj Студии и всё устраивает. дальше не читал, не дай бог где-нибудь с тобой в реальной жизни пересечься
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

109. Сообщение от 12yoexpert (ok), 12-Авг-25, 20:32	+/–
знаешь, откуда пошло имя Давид? вам в школе должны рассказывать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

110. Сообщение от 12yoexpert (ok), 12-Авг-25, 20:33	+/–
лучше бы ты букварь купил ведь вряд ли у вас в советской школе бесплатно выдают, дочам чиновников нужны свои гаремы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

111. Сообщение от Аноним (50), 12-Авг-25, 20:35	+1 +/–
Спасибо, я лучше напишу это одной строчкой `add_executable(app ...)`
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #114

112. Сообщение от Аноним (50), 12-Авг-25, 20:37	+1 +/–
Не используй обычный make даже для таких программ. Смотри: https://www.opennet.me/openforum/vsluhforumID3/137560.html#104
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

113. Сообщение от Deistvitelno_botolizm (?), 12-Авг-25, 20:39	+/–
>>Повторить линукс В смысле повторить ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #116

114. Сообщение от Аноним (7), 12-Авг-25, 20:53	+/–
Одной портянкой ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

115. Сообщение от aa (?), 12-Авг-25, 21:20	–1 +/–
cmake постоянно дропает обратную совместимость
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #119

116. Сообщение от нах. (?), 12-Авг-25, 21:21	+/–
в смысле появления какой-то другой операционной системы на базе открытых компонент. времена гну, которые пытались таки быть portable software, увы, кончились. Теперь только линукс и еще, вот, венда и венда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

117. Сообщение от нах. (?), 12-Авг-25, 21:25	+1 +/–
>> использование чего-то отличного от классического мейка неоправдано. > Как ты для себя объясняешь наличие Autotools? костыль тех древних времен, когда софт _мог_ работать не только под линуксом. Эти времена давно прошли (вот потому что все равно у тебя нет питона под твою экзотическую платформу) > Пример того самого абсурда: >> In 1991, David J. MacKenzie got tired of customizing Makefile for the 20 platforms не хотел бы тебя огорчать, но помимо мэйкфайла у него был КОД - разный для этих 20 платформ. Поэтому и приходилось кастомайзить мэйкфайлы. И этот код сам себя не написал - просто этот Дэвид был сильно неленивый. Причем ВСЕ (вот ровно ВСЕ) эти 20 платформ сегодня мертвы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #125

118. Сообщение от нах. (?), 12-Авг-25, 22:04	+/–
> - `all` цель, её обычно нет. А кому она должна? > - Прямые вызовы `gcc` типа `gcc -o foo foo.c`. У меня в > системе нет `gcc`. Нужно `${CC}` А мой код не оттестирован ни на чем другом (и в общем-то почти гарантировано не работает). Почему я должен беспокоиться о неоподдерживаемой мной системе? Это имело бы смысл только если бы существовал какой-то не такой gcc, но все еще gcc, рядом с нужным. Но такое сейчас немодно (а когда было модно - определялось CFLAGS а не заменой пути к бинарнику). > - Отсутствие флагов. не `${CC} -o foo foo.c`, а `${CC} ${CFLAGS} -o > foo foo.c`. снова очень сомнительная идея для чужого проекта. Времена каких-то уникальных CFLAGS давно прошли и имеют смысл только для переносимого софта, которого нет давно. > А `-Wall` это проекто-специфичный флаг, он должен _добавляться_, при этом безусловно. не вижу зачем тебе чужие предупреждения. Вообще ненужный в релизе флаг. > - Использование `-march=native` в любом виде. С ним соберётся непереносимый, суть битый безусловная глупость от секты свидетелей -O6 Как впрочем любой march кроме каких-то совсем уникальных кодов с интрисиками. Которые тоже писать умеет теперь только чатгопота, но они не работают. > - Использование `-Werror` в любом виде. Вне твоего локалхоста варнинги _всегда будут_. вовсе необязательно (полно софта собирающегося с Werror, и если они в таком появляются - обычно это значит что что-то поломалось - как еще донести до тебя эту новость?) > - Вызов сабмейка как make, вместо `${MAKE}`. У меня в системе `make` это вот да, мэйков все еще больше чем один. Впрочем, у тебя дальше требование не использовать диалекты, а значит мы пишем все на pmake. И тогда можем вызывать почти любой. > - Добавление библиотек через `-l` вместо `pkg-config --libs` (хотя и то и "у меня в системе нет pkg-config". Совершенно дурацкое требование. > то неправильно; правильно - как делает cmake, добавляет полный путь к > библиотекам`) и откуда автор мэйкфайла должен его взять? Тебя спросить? Ты точно помнишь куда запихнул libневедомочто.so два года назад ? Привет тут скорее твоей freelsd упрямо не желающей признать очевидное, что стандартный путь ДОЛЖЕН включать local/lib если уж вы так боитесь ставить библиотеки в корневые lib, потому что вы сами сделали base непригодной для сборки 3-d party софта в принципе, удалив половину наистандартнейших для около-юникс системы библиотек. (и та же точно хрень с -I) > - Добавление путей к инклудам зависимостей через `-I` вместо `-isystem`. gccизм неработающий вне экосистемы (у тебя работает потому что эпл его скопировал для совместимости с кривыми мэйкфайлами вместе с большей частью экосистемы - которую постепенно выкидывает) Вообще не понимаю кто и зачем его использует и что у них там такого понаустановлено. > Ты не знаешь путей на моей системе, `pkg-config` знает. Этот пункт я не знаю есть ли на твоей системе pkg-config, но на моей его либо нет либо не все пакеты о нем в курсе (потому что мне эта сущность представляется совершенно вредной) autotools, кстати, обычно способны разобраться где что. > противоречит предыдущему потому что `pkg-config` обычно отдаёт `-I` вместо `-isystem`. потому что даже его авторы старались сохранить условно-независимость от тулсета > - Установка не в ${PREFIX}. очень сомнительная идея. Потому что по задумке была для _работы_ в этом prefix. Что мой код может просто не поддерживать. > - Установка не в ${DESTDIR}. ну ок, допустим, в эпоху повсеместного опакечивания имеет смысл. > - Установка в нестандартные директории типа `${PREFIX}/games/bin` или `${PREFIX}/lib64`. lib64 - линуксизм, худо-бедно и не всегда правильно (т.е. угадав не всегда срабатывает как надо) детектируемый большинством генераторов и/или самодельными мэйкфайлами. Не поддерживать нельзя, все попереломаешь. Падаждити еще лет десять, останется только один. > На самом деле, установка по любым захардкоженным путям. Правильно - cmake'вский > `GNUInstallDirs` это чтоб хрен ты его поменял? (вот например когда он на тот самый lib64 напорется, и не угадает) > - Извращения с вызовом git чтобы узнать версию проекта из тэга. Хотя ну тут мэйк непричем, онитаквидют. В конце-концов, надо ж где-то эту версию взять. (понятно что она должна быть на самом деле статикой и извлекаться мерж-хуком, заодно вот и в архив попадет правильная, но куда им, они и configure-то в _релизнутые_ архивы разучились класть) > - Про поддержку кросскомпиляции даже заикаться не буду. Справедливости ради, её и Потому что она и не нужна. > cmake не умеет. Ее использующие cmake проекты не умеют. Не соберется и работать не будет как ни старайся (даже если native компиляция под эту платформу и есть) Это требует совершенно отдельных упражнений от автора, ставших совершенно бессмысленными в виду немодности кросскомпиляций обычными компиляторами (необычные используют chroot и другие корявые способы гарантировать что в сборку не засосет include от сборочной системы, и по другому это не работает уже тоже давным-давно) > Ну и не буду даже упоминать такие банальные вещи как то что > make не умеет в нормальную параллельную сборку, даже cmake и meson Что такое "нормальная"? > генерят ninja файлы. И не умеет генерацию ide проектов что абсолютно болтали о переносимости, опа, python 4.99+ required, приехали. А зачем нам тогда - переносимость? > обязательно для системы сборки. совершенно необязательно, автору оно может быть нахрен не надо > Ну и на звёздочку - настоящий переносимый Makefile должен поддерживать gnu и > bsd диалекты. Удачи с этим. ну в целом, использование гнусизмов вместо рекурсивного make вообще плохая идея.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #152

119. Сообщение от Аноним (91), 12-Авг-25, 22:11	+/–
Как скажешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

120. Сообщение от Аноним (120), 12-Авг-25, 22:32	+/–
Они переизобретают старый недобрый scons? Байтораздирающее зрелище.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

121. Сообщение от Аноним (121), 12-Авг-25, 23:56	+/–
Чел фигню написал, .pro компилируется чисто в консоли и без Creator'а. И формат мультиплатформенный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

122. Сообщение от Илья (??), 13-Авг-25, 03:04	+2 +/–
Сам питон не так страшен, как люди, которые его используют. всякие "я прошёл курсы по питону 2 года назад" пугают меня
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

123. Сообщение от Аноним (-), 13-Авг-25, 04:45	+/–
> Так питон идеальный язык для быстрого написания скриптов. Разве не так? Только это уг потом разваливается раз в полгода. И через пару лет 90% этого хлама просто не запускается или не работает уже. > И да, meson открой для себя. Он, к счастью, не питон. Настолько что есть, например, muon. Реализация meson на C99. Так что если не хочется связываться с питоноляпой и hype driven dev - это можно! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

124. Сообщение от Аноним (-), 13-Авг-25, 04:47	+/–
> Питон это Meson или Conan Meson сам по себе - DSL. Всего лишь. И поэтому существуют реализации типа Muon - на C99 с минимумом зависимостей вообще. Если вон то лохматое черти что на питоне не хотелось, а проект с мезоном билдануть хочется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

125. Сообщение от Советский инженер (ok), 13-Авг-25, 09:06	+/–
> ... когда софт _мог_ работать не только под линуксом. софт, который работает только под линуксом - это либо что-то типа systemd либо никому нинужно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #147

127. Сообщение от Аноним (45), 13-Авг-25, 09:29	+/–
Как же ты поверхностно мыслишь. Дальше своего носа вообще не видишь. Make не под какие-то твои редкие частные задачи сделан. Он гораздо глубже продуман для общего использования и с минимальными навешиваниями обязаловок на пользователей, а ты, как типичная веб-м*к*ка, которая готова все и вся повязать, потому что тебе это вот прям сейчас вот так вот нравится/удобно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #128, #157

128. Сообщение от Советский инженер (ok), 13-Авг-25, 13:10	+/–
вот из-за того что мейк такой продуманный и минималистичный, он сам по себе нафик никому ненужен. разве что для хеллоуворда. и то не для каждого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #137

129. Сообщение от Аноним (26), 13-Авг-25, 13:19	–1 +/–
> make не умеет в нормальную параллельную сборку Враньё, make -j16 и всё на 16 потоков раскидывается. Так же как враньё что нинзя якобы быстрее мейка, во всяком случае на типичных проектах это не так. А учитывая что иде по кнопке будет не нинзю напрямую вызывать, т.к. структура проекта могла измениться, а мезон / смаке, то всё это становится наоборот медленнее нормального мейка. > не умеет генерацию ide проектов Нафига, это иде должна импортировать проект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #130

130. Сообщение от Советский инженер (ok), 13-Авг-25, 13:43	+/–
> т.к. структура проекта могла измениться а как мейк про это "узнает" ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #131

131. Сообщение от Аноним (26), 13-Авг-25, 13:52	+/–
Он чекает все файлы, их даты изменения, и даты изменения соответствующих объектных файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #134

132. Сообщение от SKZ (?), 13-Авг-25, 14:13	+/–
Скрипты autotools, ЕМНИП, до сих пор не могут в кросс-компиляцию, пытаясь запускать объектный код целевой платформы на сборочном хосте. Впрочем, всему, что не х86, пора на свалку истории.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

133. Сообщение от SKZ (?), 13-Авг-25, 14:20	+/–
Как бы мне модули ядра посредством штатного *.про скомпилировать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

134. Сообщение от Советский инженер (ok), 13-Авг-25, 14:47	+1 +/–
> Он чекает все файлы что значит все? все во всей доступной файловой системе? как тогда он определяет какие файлы принадлежат проекту? или он чекает файлы записанные в мейкфайле. тогда ворос прежний: как make может узнать про изменение структры проекта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #136

135. Сообщение от Александр (??), 13-Авг-25, 15:11	+/–
Ещё близкая к нему premake5. Тоже Lua.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

136. Сообщение от Аноним (26), 13-Авг-25, 15:17	+/–
в указанной папке/папках очевидно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

137. Сообщение от Аноним (45), 13-Авг-25, 17:21	+/–
А может кто-то пытается через make кувыркатьс с симптомами в работе, а не решать проблему? Может задачу нужно ставить корректно, а не через ж*пу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #139, #140

138. Сообщение от Аноним (138), 13-Авг-25, 17:36	+1 +/–
> Кто в здравом уме в 2к25 будет планировать стартап под венду? (с tadviser) К концу 2024-го, по оценкам, суммарная доля разных ОС Windows в глобальном масштабе достигла 73,38%. Увеличившись за год почти на процент. И тут ты такой умный заявляешь: - Зачем нам стартап для венды с долей в 70 с лишним процентов, когда мы можем взять линукс аж с 4,13%. У тебя там случайно мозги на череп не давят?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

139. Сообщение от Аноним (139), 13-Авг-25, 17:50	+/–
> А может кто-то пытается через make кувыркатьс с симптомами в работе Ну да, возможно. Хотя странно: в предыдущем сообщении ты вроде make защишал. 🤔
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

140. Сообщение от Советский инженер (ok), 13-Авг-25, 19:14	+/–
> А может кто-то пытается через make кувыркатьс с симптомами в работе ... ну не знаю. ты мне лучше скажи какой более менее популярный проект собирается чисто make без автотулзов/симейков/перлов/питонов и подобного. вот чисто компилятор и make. сможеш?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #144, #151

141. Сообщение от Советский инженер (ok), 13-Авг-25, 19:17	+/–
ну, как бы, из-за этого я и ожидаю что его скоро вообще выкинут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

143. Сообщение от Bottle (?), 13-Авг-25, 21:43	+1 +/–
Был, есть, и будет, но платформозависимый. Под Линь один мейк, под бзду другой, а симейк - один на все ОСи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

144. Сообщение от fee (?), 13-Авг-25, 21:45	+/–
> ты мне лучше скажи какой более менее популярный проект собирается чисто make без автотулзов/симейков/перлов/питонов и подобного. много какие для bare metal, и также например suckless.org.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

145. Сообщение от Bottle (?), 14-Авг-25, 00:26	+/–
Да, а сколько компилятор и системные либы весят - не представляешь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

146. Сообщение от нах. (?), 14-Авг-25, 16:40	+/–
> Кроссплатформенным инструментом является cmake, а не его выхлоп. А выхлоп autoconf - внезапно, является. > ...получившийся Makefile будет работать autoconf не производит Makefile. Он производит их генератор, который таки да, будет. БЕЗ необходимости устанавливать autotools (может они вообще туда не спортированы еще) и вообще что-либо за пределами posix-среды. Чем и хорош.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

147. Сообщение от _ (??), 14-Авг-25, 16:44	+/–
Ну да, ну да(С) :) Или к примеру практически любой новый графоний, там по цепочке зависимости на linux-only  почти всегда... Хотя да даже если серверный софт завязать на systemd и где ещё ты его запустишь? А завязывают во-всю.. > либо никому нинужно Дык линукс жи! :) У вас всегда если что-то не работает (чего то тупо нет) - то оно и нинужнаааа!(С) ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

148. Сообщение от _ (??), 14-Авг-25, 16:52	+1 +/–
Справедливости ради - большинство перечисленного о том как микроскоп использовали для забивания шурупов и завёртывания гвоздей... :) > У меня в системе нет `gcc`. Нужно `${CC}` > У меня в системе `make` не то что ты думаешь. А вот прямо интересно стало ... систему свою озвучишь? > Ну и на звёздочку - настоящий переносимый Makefile должен поддерживать gnu и bsd диалекты. Боюсь - _уже_ нет! :( Хорошая часть софта в бздяхах без gnu make уже не соберётся... > Удачи с этим. Да упырь свой мел!(С) :) Тупо ставят gnu make и в BSD и в форточки и в яббблы ... Как то так!(С) :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #155

151. Сообщение от _ (??), 14-Авг-25, 17:18	+/–
> сможеш? Ну классика жи! https://wiki.osdev.org/Building_GCC
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

152. Сообщение от Аноним (-), 14-Авг-25, 19:10	+/–
> А мой код не оттестирован ни на чем другом (и в общем-то почти гарантировано не работает). Почему я должен беспокоиться о неоподдерживаемой мной системе? Потому что если к тебе придёт доброволец, который решит оттестировать, он будет для начала вынужден выкинуть твои Makefile'ы и написать их заново. > снова очень сомнительная идея для чужого проекта. Времена каких-то уникальных CFLAGS давно прошли и имеют смысл только для переносимого софта, которого нет давно. Дистрибутив может собирать твой код со своими CFLAGS. Причём под разные платформы или под ещё какие переменные факторы, он может использовать разные CFLAGS. При этом, патчинг сорцов (включая сюда и мейкфайлы) для мейнтенеров - это дополнительная головная боль. > потому что даже его авторы старались сохранить условно-независимость от тулсета Ага. Эта условная независимость выливается в некоторых случаях в то, что мне приходится добавлять переменных окружения, чтобы мой проект с зависимостями на Makefile'ах собирался бы. Потому что... Ну потому что. > и откуда автор мэйкфайла должен его взять? Надо знать способы. В случае make'а другого способа нет. Например, я выставляя те упомянутые выше флаги, использовал `llvm-config --prefix`, чтобы получить путь к директории с библиотеками llvm. Но заклинания могут быть (и будут) разными для разных пакетов. > Это требует совершенно отдельных упражнений от автора, ставших совершенно бессмысленными в виду немодности кросскомпиляций обычными компиляторами (необычные используют chroot и другие корявые способы гарантировать что в сборку не засосет include от сборочной системы, и по другому это не работает уже тоже давным-давно) Gentoo может. Не, ты прикинь, да? У кого-то нет способов, и не работает давным-давно, а мейнтейнеры Gentoo справляются. Может у кого-то руки кривые просто? > Потому что она и не нужна. Это называется "зелен виноград" и проистекает из того, что ты слаще редьки ничего не едал. Я регулярно собираю под arm и mips. Я пробовал это делать до миграции на rust, и это было такой болью... Даже в gentoo. Но когда это делается добавлением одного флага к вызову cargo build, это настолько удобно, что просто не описать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #153

153. Сообщение от нах. (?), 14-Авг-25, 19:31	+/–
> Потому что если к тебе придёт доброволец, который решит оттестировать, он будет для начала > вынужден выкинуть твои Makefile'ы и написать их заново. нет, для начала он должен будет написать вагон и маленькую тележку своего кода под специфическую платформу. А там и посмотрим, дойдет ли до "переписывания". > Дистрибутив может собирать твой код со своими CFLAGS. в этом нет ни малейшего смысла, о член секты свидетелей -O6. Поэтому нет смысла и беспокоиться. > Надо знать способы. В случае make'а другого способа нет. способа просто нет. Есть только костыли. > Gentoo может. Не, ты прикинь, да? У кого-то нет способов, и не работает давным-давно, а > мейнтейнеры Gentoo справляются. Может у кого-то руки кривые просто? или кто-то звиздит (и те таки используют сборку в chroot). У меня, чтоб ты знал - стоит инструментарий для кросс-сборки. Там мало chroot, там целая куча модных-молодежных фокусов с оверлейфс и тому подобным. (кроме хеловрота все равно ничего таким не собрать - ну вот к примеру из-за configure, которая не работает) > Я регулярно собираю под arm и mips. Я пробовал это делать до миграции на rust, и это > было такой болью... Даже в gentoo. Но когда это делается добавлением одного флага к > вызову cargo build то ись речь о хеловротах на хрусте с переписанными с нуля всеми системными библиотеками (хеловротах потому что будь они не хеловротами им таки бы понадобились немодные-немолодежные библиотеки других проектов) - под все те три платформы на которых заводится хруст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #156

155. Сообщение от нах. (?), 14-Авг-25, 19:43	+/–
>> Ну и на звёздочку - настоящий переносимый Makefile должен поддерживать gnu и bsd >>диалекты. > Боюсь - _уже_ нет! :( > Хорошая часть софта в бздяхах без gnu make уже не соберётся... хорошая часть плохого современного софта без ручного патчинга в любой системе отличной от systemd/linux и wsl - вообще не соберется или работать не будет. А переносимый софт, там где уж остался по недоразумению - таки стоит писать переносимым образом. используя поменьше питонозависимых и зависящих от самих себя автоматик в том числе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

156. Сообщение от Аноним (-), 14-Авг-25, 22:01	+/–
> нет, для начала он должен будет написать вагон и маленькую тележку своего кода под специфическую платформу. А там и посмотрим, дойдет ли до "переписывания". Ты видимо не знаком с разработкой от слова вообще? Ему придётся начать с переписывания мейкфайлов, для того, чтобы он мог бы писать свой код. Ему надо компилировать, ему надо запускать и тесты, и программу в целом. А для этого ему нужна билдсистема, которая будет поддерживать добавление ещё одной платформы. > в этом нет ни малейшего смысла Иди расскажи об этом мейнтейнерам дистрибутивов. Скажи им что они глубоко заблуждаются, и что они могут сэкономить ресурсы, если позволят тебе вправить им мозги. > то ись речь о хеловротах на хрусте с переписанными с нуля всеми системными библиотеками О да, это мои программки для меня любимого, которые я гоняю на малинке или на роутере. Что-то более серьёзное, с какими-нибудь C'шными депендансами несомненно упрётся в то, что в C кроссплатформенность боль. О чём я собственно и говорю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

157. Сообщение от Аноним (-), 14-Авг-25, 22:13	+/–
> Он гораздо глубже продуман Ой, не смешите мои тапочки. "make продуман". Он был слеплен на коленке, это сквозит изо всех его щелей, а потом на него накрутили сверху всяких плюшек, пытаясь костылями подпереть его под общий случай. Если бы он был продуман, как ты говоришь, то проблему генерации депендансов не пришлось бы приматывать к нему изолентой, в нём заранее был бы задуман штекер, куда можно воткнуть внешний генератор депендансов. Если бы он был продуман, то он бы задавал стандартную структуру директорий, чтобы структуру проекта можно было бы описывать создавая директории и раскладывая по ним файлы. Чтобы не было бы необходимости все эти вещи проделывать дважды - один раз в файловой системе, второй раз в мейкфайлах. И к этой стандартной структуре он бы предлагал стандартные цели, типа release, debug, test. То есть, в проекте, который ты решил собрать make'ом, и который не имеет Makefile, было бы достаточно сделать `touch Makefile && make release` и проект бы собрался. Если бы он был бы очень хорошо продуман, то он позволял бы описывать нестандартную структуру директорий, не скатываясь в ту ситуацию, в которой make находится сейчас. Это если бы он был продуман. Но реально он был слеплен из того, что было. Декларативный язычок для описания зависимостей между этапами сборки, и научили make поглядывать на даты файлов, с тем чтобы не выполнять все этапы сборки каждый раз. Это базовая функциональность make. Ещё ему приделали переменные, чтобы как-то можно было бы конфигурировать. Всё остальное -- это костыли, которые позволяют решать при помощи инструмента задачи, для которых он не предназначен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

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

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