evgeniy1294 (13.11.2023 09:32 - 09:37, просмотров: 186) ответил ig_z на А почему такой вердикт о cmake? Я им активно не пользовался пока,
прослушал на юдеми курс, у меня сложилось впечатление, что связка
cmake, conan | vcpackage вполне себе современная молодежная
свистоперделка.-
- А главное - непонятно нафига. Мейк же примитивен, он только
разрешает зависимости да смотрит время изменения файлов. А что ещё
нужно то? Если для сборки этого не хватает - всегда можно дописать
скрипты или вспомогательные утилиты на любом удобном языке. Причём
собирать их можно тем же мейком прямо в процессе. - =AlexD=(13.11.2023 09:38)
- Допиши и удивить, сборочные утилиты бывают сложнее проекта. Make
умер, ещё в 90х не справлялся с задачей. evgeniy1294(51 знак., 13.11.2023 09:41)
- Кернел Линуха собирается обычным мейком и не жужжит. Некоторые
вспомогательные утилиты собираются в процессе прямо из сишечки. - =AlexD=(13.11.2023 10:34)
- >>> SciFi(1 знак., 13.11.2023 10:36, ссылка)
- И? Проблема большинства языков в том что они плохо в исполнение до
компиляции умеют. А Сишечка и вовсе не умеет. И это никакими
костылями не исправить. make по крайней мере прост и есть всегда.
Все остальные костыли - не читаемы в принципе. Поэтому без разницы
чем подпереть. - =AlexD=(13.11.2023 10:43)
- Что тут нечитаемого? Тоже самое придется указать и в make, ни на
строчку короче не будет: evgeniy1294(3050 знак., 13.11.2023 10:52)
- Когда я говорю про нечитаемось, я говорю про исполнение неких программ в процессе сборки. Которые должны что-то создать исходя из контекста среды компиляции. И эти программы будут по любому нечитаемы, потому что требуют к себе понимание исходников самой программы. Что ей там нужно для сборки. Честнее тупо создать некую build_utilites и собрать/вызвать её из make, но не тянуть весь этот трешовый код в некий птичий язык сборки проекта. - =AlexD=(13.11.2023 11:01)
- Всё тоже самое делается в make , только короче. Спрашивается,
нафига ещё одна дублирующая сучность? Изучать ещё одну утилиту
что-бы что? Может потратить это время на углубление понимания make? - =AlexD=(13.11.2023 10:56)
- На make оно может быть короче только при условии предварительного
задания переменных окружения. Вот тебе ссылка, перепиши на make: evgeniy1294(1 знак., 13.11.2023 12:30, ссылка)
- Переменные среды - это как просто переменные, но которые можно
передать в BASH, что очень удобно во многих случаях, в отличии от
ваше б-гмерзской луа. - =AlexD=(13.11.2023 13:10)
- Нет, это не просто переменные. Это платформозависимая часть системы
сборки, которую мне придётся делать самостоятельно, если мой
дистрибутив отличается или я хочу использовать другой тулчейн для
сборки. Особенно плохо с этим на Windows, где для сборки софта под
платформу приходится делать целую отдельную песочницу. И никакую
сборочную утилиту тут не сделать. evgeniy1294(235 знак., 13.11.2023 13:34)
- Никто не заставляет использовать тебя именно системные переменные и
даже пути. Всё можно описать вручную. В общем, надуманные
трудности. В кроссплатформенности свои проблемы, более существенные
чем утилита сборки проекта. - =AlexD=(13.11.2023 14:25)
- Изначально вы мне пытались показать, что на make "будет короче", я
указал, что короче не будет и объяснил почему - вам нужно
предоставить одну и ту же информацию одной и той же программе
(gcc). И нет, это не надуманные трудности, приводящие в конце
концов к виртуальной машине/контейнеру, в которой строго
определённое окружение для разработки софта, не меняющееся годами в
целях длительной поддержки продукта. И это не плохой вариант,
бизнесу плевать как сделано, пока это evgeniy1294(28 знак., 13.11.2023 15:52)
- Короче - это меньше буков, а не строчек. А так да, всё то же самое
только другим йезыком, ну и нахуа? Вот вы уже и оправдываетесь, что
оно "то же работает". Ну собственно я и не сомневался. Одно и то же
можно сделать 100500 разными способами. Никто вам не запрещает
написать сборочный скрипт на Питоне, к примеру. И у этого будут
определённые свои достоинства, даже и поболее вашего xmake. - =AlexD=(13.11.2023 15:59)
- Вы плохо себе представляете, что такое сложный продукт и его
длительная поддержка, иначе про make даже не думали бы. А смысл в
экономии времени и удобстве, причём очень серьёзном. Когда у вас
будет комплекс с десятком сложных устройств, в каждом из которых на
линухе крутится своё ПО, собранное с кучей зависимостей начиная от
cuda и заканчивая libre-office-dev, а поддерживать это нужно 10 лет
- вы взвоете. - evgeniy1294(13.11.2023 16:17)
- Видел такое. Собирается строго в среде конкретного дистрибутива Линуха с точностью до второй цифры. Куча скриптов в которых чего только нет. Куча make, куча питоновских скриптов. xmake - нет, не видел. Проще было бы распространять образ виртуального диска либо Докер контейнера. - =AlexD=(14.11.2023 10:25)
- Вы плохо себе представляете, что такое сложный продукт и его
длительная поддержка, иначе про make даже не думали бы. А смысл в
экономии времени и удобстве, причём очень серьёзном. Когда у вас
будет комплекс с десятком сложных устройств, в каждом из которых на
линухе крутится своё ПО, собранное с кучей зависимостей начиная от
cuda и заканчивая libre-office-dev, а поддерживать это нужно 10 лет
- вы взвоете. - evgeniy1294(13.11.2023 16:17)
- Короче - это меньше буков, а не строчек. А так да, всё то же самое
только другим йезыком, ну и нахуа? Вот вы уже и оправдываетесь, что
оно "то же работает". Ну собственно я и не сомневался. Одно и то же
можно сделать 100500 разными способами. Никто вам не запрещает
написать сборочный скрипт на Питоне, к примеру. И у этого будут
определённые свои достоинства, даже и поболее вашего xmake. - =AlexD=(13.11.2023 15:59)
- Изначально вы мне пытались показать, что на make "будет короче", я
указал, что короче не будет и объяснил почему - вам нужно
предоставить одну и ту же информацию одной и той же программе
(gcc). И нет, это не надуманные трудности, приводящие в конце
концов к виртуальной машине/контейнеру, в которой строго
определённое окружение для разработки софта, не меняющееся годами в
целях длительной поддержки продукта. И это не плохой вариант,
бизнесу плевать как сделано, пока это evgeniy1294(28 знак., 13.11.2023 15:52)
- Никто не заставляет использовать тебя именно системные переменные и
даже пути. Всё можно описать вручную. В общем, надуманные
трудности. В кроссплатформенности свои проблемы, более существенные
чем утилита сборки проекта. - =AlexD=(13.11.2023 14:25)
- Нет, это не просто переменные. Это платформозависимая часть системы
сборки, которую мне придётся делать самостоятельно, если мой
дистрибутив отличается или я хочу использовать другой тулчейн для
сборки. Особенно плохо с этим на Windows, где для сборки софта под
платформу приходится делать целую отдельную песочницу. И никакую
сборочную утилиту тут не сделать. evgeniy1294(235 знак., 13.11.2023 13:34)
- Переменные среды - это как просто переменные, но которые можно
передать в BASH, что очень удобно во многих случаях, в отличии от
ваше б-гмерзской луа. - =AlexD=(13.11.2023 13:10)
- Логика китайцев вообще не поддается никакой логике ☺ Eddy_Em(313 знак., 13.11.2023 11:34)
- Ну я осилил cmake, и что? Да, это отраслевой стандарт, поэтому все мои проекты сделаны на нём ради преемственности кода, но не более. Он требует гораздо больше усилий, как следствие денег. В следующем году напишу плагин для QtCreator и буду дублировать сборочные скрипты на xmake, буду популяризировать систему и привлекать людей. В первую очередь нужна инфраструктура. evgeniy1294(172 знак., 13.11.2023 12:40)
- На make оно может быть короче только при условии предварительного
задания переменных окружения. Вот тебе ссылка, перепиши на make: evgeniy1294(1 знак., 13.11.2023 12:30, ссылка)
- Что тут нечитаемого? Тоже самое придется указать и в make, ни на
строчку короче не будет: evgeniy1294(3050 знак., 13.11.2023 10:52)
- И? Проблема большинства языков в том что они плохо в исполнение до
компиляции умеют. А Сишечка и вовсе не умеет. И это никакими
костылями не исправить. make по крайней мере прост и есть всегда.
Все остальные костыли - не читаемы в принципе. Поэтому без разницы
чем подпереть. - =AlexD=(13.11.2023 10:43)
- >>> SciFi(1 знак., 13.11.2023 10:36, ссылка)
- У нас тут МК и мигающие лампочки. Достижения 90-х вполне
справляются с задачей. Некоторые ещё и до сей не дошли, застряли в
60-х :-) - SciFi(13.11.2023 09:45)
- Увы, нет. У нас уже давно ТCP, файфай, тачскрины, веб-интерфейсы и
даже кое-где SQL. Cкpипaч(33 знак., 13.11.2023 09:59)
- У меня есть TCP и вебморды. Мейк легко справляется. Впрочем, я не настаиваю. - SciFi(13.11.2023 10:02)
- Увы, нет. У нас уже давно ТCP, файфай, тачскрины, веб-интерфейсы и
даже кое-где SQL. Cкpипaч(33 знак., 13.11.2023 09:59)
- +1. При этом в других языках, в которых модульность не является побочным эффектом макроподстановки, уже в начале 90х собирались проекты любого уровня сложности. - Cкpипaч(13.11.2023 09:43)
- Кернел Линуха собирается обычным мейком и не жужжит. Некоторые
вспомогательные утилиты собираются в процессе прямо из сишечки. - =AlexD=(13.11.2023 10:34)
- Допиши и удивить, сборочные утилиты бывают сложнее проекта. Make
умер, ещё в 90х не справлялся с задачей. evgeniy1294(51 знак., 13.11.2023 09:41)
- Что касается пакетный менеджеров, то есть только один - системный. И вам всё равно придётся писать свой пакет под выбранный дистрибутив. evgeniy1294(143 знак., 13.11.2023 09:35)
- А главное - непонятно нафига. Мейк же примитивен, он только
разрешает зависимости да смотрит время изменения файлов. А что ещё
нужно то? Если для сборки этого не хватает - всегда можно дописать
скрипты или вспомогательные утилиты на любом удобном языке. Причём
собирать их можно тем же мейком прямо в процессе. - =AlexD=(13.11.2023 09:38)