1.1, Аноним (1), 11:16, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Оно еще выходит? Неплохо.
Хорошая замена всему этому синтаксическому недоразумению в других сборочных тулзах.
| |
|
2.5, Аноним (5), 13:36, 02/05/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
А чем тебе месон не угодил? Хотя и как альтернатива цмаке так себе.
| |
|
3.8, Ivan_83 (ok), 18:00, 02/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
А в чем минусы месона?
(спрашиваю потому что cmake кажется каким то тяжёлым по зависимостям)
| |
|
4.15, Аноним (11), 18:42, 02/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вообще-то у CMake только одна тяжелая зависимость - это сам CMake.
Хоть я до Kotlin не особо любил Java, и наоборот любил C/C++, но после этой насмешки над всеми C-подобными языками под именем CMake (ибо неясно, что делает буква C в его названии)...
...после всего этого Java-шный Gradle на стероидах Kotlin DSL, со всеми архитектурными изъянами Gradle и со всеми его зависимостями воспринимается гораздо приятнее, чем это издевательство над C/C++ под названием CMake.
На Gradle внезапно прекрасно собираются проекты на разных языках, включая C/C++.
Увы, видимо сделать архитектурно красивую систему сборки невозможно в принципе из-за неясности вопроса - а что же такое сборка в общем случае? В частном же случае всегда можно написать просто сборочные скрипты на чем угодно - и будет вам сборка!
| |
|
5.23, anonimm (?), 09:19, 03/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
В CMake C=Crossplatform, а не C/C++. Не знаю, чем Вам не угодил CMake, но тащить Java в C/C++-разработку выглядит ещё бОльшим издевательством.
| |
|
6.33, Аноним (32), 10:08, 04/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
cmake неугоден:
- синтаксисом,
- набором инструментария (FindLibrary)
- сложностью написания и анализа сборочны сценариев
| |
6.35, Аноним (11), 14:40, 04/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Издевательство над чем?
Над сферичным конем в вакууме?
Вот создатели CMake нагло поиздевались над языками программирования, ради сборки проектов на которых, какбы все это создавалось.
А над чем у вас будет издеваться Java? особенно в переводе на Kotlin, если можно сделать так, что вся JVM и останется только в среде разработке, а в продакшн уйдут чистые бинари (или теперь даже байт-код на другие VM, отличные от JVM, если не устраивает).
Даже при всех недостатках Java, которые можно себе нафантазировать (а обычно это именно фантазии и байки, см. ниже) - сборка на Gradle, даже при всех недостатках и его тоже - по-любому получается "меньшим из зол" по сравнению с CMake.
Это я говорю, как начинавший с C/C++, и долго его изучавший, кому тоже не нравилась когда-то Java по сравнению с C++, говорю:
- времена изменились!
- Java сильно исправилась (и по времени эти исправления "случайно" совпали с выходом новых стандартов 11+ самого C++).
Да, у Java был долгий путь развития, однако это уже прошлое.
А если вам нужна простая классическая сборка без автоанализа и автозагрузки зависимостей с авто-тестированием и стиркой белья разработчикам (ну если заказчик или спонсор требует, для создания рабочих мест его менеджерам, которым иначе нечем будет больше заняться после внедрения)
... если этого всего не нужно
- просто напишите сборочный скрипт, и не нужен ни CMake, ни Gradle...
... только сейчас все больше в моде всякие CI/CD, и уже никуда не денешься от сложных сборочных уже даже фреймворков с интегрированным Agile-планированием и чатом с поддержкой визуализированных тикетов для Scrum-мастера, не умеющего читать код...
...в-общем от качества DSL для разработчиков сейчас все зависит гораздо больше, чем от нескольких лишних зависимостей в сборочном окружении... а если сборочное окружение удается вообще выпилить из продакшена... скоро видимо везде будут одни сплошные сборочные окружения... ну и возитесь там сами с этим CMake!
| |
|
5.29, Ivan_83 (ok), 01:22, 04/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Там ещё libuv и ещё штук 5+ портов ставится на фре.
Но да, сам цмейк собирается дольше остальных. Заметно дольше.
Я ничего не знаю про то что вы описываете, я подобные сборочные системы скорее всего не встречал в тех портах которыми пользуюсь.
Самое экзотическая система сборки которую видел - waf - какая то фигня на питоне, вроде.
В общем я пока смотрю на месон и пытаюсь понять: стоит ли на него сваливать с цмейка в своих перснальных проектах.
Как вариант я могу иметь обе системы, но хотелось бы понять перспективы.
| |
|
4.18, Аноним (18), 20:06, 02/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Минус в том, что это — боль для сборщика и потребность учить питон для кодера. (Вот только не надо про то, что питон знают все, и уж тем более про то, что там нечего учить.)
| |
|
5.25, Аноним (11), 09:43, 03/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Поэтому лучше уж выучить Kotlin, чем Python. Или хотя бы Kotlin DSL. Там, в отличие от Питона, есть полноценная система статических типов с выводов.
Поскольку сборка в основнов и используется для статически типизированных языков.
А в динамических скриптовых языках чего там собирать? Если все и так в рантайме.
И в отличие от Qbs, Kotlin - это все-таки язык общего назначения, и даже Kotlin DSL используется в разных системах, а не только в одной системе сборки. Как и Python, зато еще и со статически компилируемыми типами.
В Kotlin поддержка функционального программирования, в Python ФП практически никакое, одни только лямбды, как объекты первого класса - это еще не ФП. А вот неизменяемые переменные, хвостовая рекурсия... это уже...
Кстати, в И-нете есть много синтаксических сопоставлений Kotlin и Python. Именно синтаксических, если кто захочет докопаться, семантика у них разная. Однако это про то, как легко перейти с Python на Kotlin. Да, вместо отступов - старые добрые Сишные фигурные скобочки, зато не нужно ставить ";" в конце строк. И скобки во многих случая можно не использовать - код получается не менее компактным, чем в Python, а за счет более развитого синтаксиса - еще и более компактным.
О да! Будете иметь дело с JVM! Однако, по сравнению с CMake, который типа на чистом C (или C++? - неважно), однако извратили так, что уж лучше пусть будет JVM.
...а чем это мы? А! ...и вот представьте все это есть у вас в системе сборки!
| |
|
6.30, Ivan_83 (ok), 01:25, 04/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Мне не типы нужны, мне проекты собирать :)
Развитый синтаксис - много времени на изучение, вон кресты себя активно хоронят: скоро старые спецы помрут а новые не пидут, потому что учится 3-5 лет чтобы получать столько же сколько те кто учился языкам по проще за пол года смысла нет.
| |
|
7.34, Аноним (11), 13:56, 04/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вам не нужны типы - тогда Питон для вас самое то. Никто не спорит.
А есть такие люди, которым нужны типы, И, одновременно им нужно собирать проекты.
А также если этим людям не проблема изучать статически-типизированные языки - то для них системы сборки с типами, встроенными прямо в сборочный DSL - тоже самое то.
Каждому свое. По способностям и по возможностям к освоению.
C++ ни разу не хоронят, особенно после стандартов 11+, он живее всех живых. Просто он придерживается классической схемы, когда компилятор отдельно, а тулсеты, включая пакетные менеджеры - отдельно. И не встроены в язык, как объекты первого класса, потому что фишка C++ - это филигранное управление памятью с одновременным высоким уровнем абстрактных типов данных.
Да, у C++ появилось много достойных конкурентов, даже Java подтянули, до уровня "нескучности", хоть и оставив многословность, ну, это как раз и исправляет Kotlin.
А тут еще даже Haskell активно пробивается в "промышленность" из "академичности"...
А еще потребности Data Science...
Так что людям, _способным_ осваивать абстрактные типы данных, и делать _сборки_ сразу не понижая уровни абстракций
- есть где развернуться!
| |
|
|
5.28, Ivan_83 (ok), 01:15, 04/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну это можно писать тому кто не видел месона и ничего с ним не делал.
Как сборщик - я как раз вижу что месон требует меньше зависимостей прежде чем он станет рабочим в системе.
Как программист - учить Cmake с его самобытным синтаксисом или месон с питоноподобным - последнее кажется более перспективным.
Хотя я лично очень плохо воспринимаю ихние пробелы и pep8 (к месону пока не относится).
Но мне приходится колупатся в опенсорсных проектах и с месоном и цмейком, при этом на месоне почему то мне или вообще не приходится ничего делать (наверное пока не так распространёт) или там сразу всё очень компактно и понятно (опять же может мне просто везло).
На цмейк это часто какие то простыни откровенного говнокода.
Не знаю, может быть все сборочные системы обречены скатыватся в УГ и становится на вид как автотулс, и цмейк просто старше и ближе а месон ещё только в начале пути.
И лично мои проекты были уже на автотулс, и я смигрировал их на цмейк.
И меня смущает обилие зависимостей цмейк на фоне мезона.
Но объективно фатальных недостатком месона пока я не услышал.
| |
|
|
|
|
|
|
3.12, Аноним (11), 18:25, 02/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вылезает потом такой мертвец из могилы и говорит: "Ха ха ха! А я - qmake!"
| |
|
|
5.22, Аноним (11), 09:12, 03/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Чем примитивнее юмор, тем древнее тенденция... Ибо сказано в Писании...ЫЫЫЫ!... Чем глубже закопать, тем страшнее потом вылезет!
| |
|
|
|
|
1.10, Аноним (10), 18:15, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Qbs - не поддерживают.
А почему он всегда самой последней вресией присутствует в Qt Creator ?
| |
|
2.13, ABBAPOH (ok), 18:28, 02/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Потому что сделать апдейт ревизии сабмодуля ничего не стоит=)
На самом деле, бывший мейнтейнер Qbs продолжает пилить интеграцию в креаторе
| |
|
1.17, Аноним (17), 19:58, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Самая удобная система сборки для c++. Стоит того, чтобы отвязать ее от Qt.
| |
|
2.20, ABBAPOH (ok), 22:08, 02/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Но зачем? Чем мешает зависимость от Qt? Ну приедет 2-3 библиотеки (QtCore/QtScript/QtGui), сильно страшно что ли?
Надо добавлять поддержку других языков и библиотек (boost, poco) из коробки - это да. Собственно, я работаю над этим=)
| |
|
3.24, anonimm (?), 09:22, 03/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если Вам нужно собрать Ваш проект на сервере, на котором у Вас есть учетка, но нет прав установить Qt, а админ не хочет "загаживать сервер всяким гуёвым хламом" (да, бывают и такие)?
| |
|
4.26, Аноним (26), 10:42, 03/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
А можно ещё вприсядку это самое. А админ, который не хочет делать свою работу, заменяется другим.
| |
4.27, ABBAPOH (ok), 14:12, 03/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Поставьте Qbs в хомяк вместе с библиотеками, делов-то. Требование "использовать системную Qt" достаточно странное, не все диcтрибы имеют свежую Qt.
| |
|
|
|
|