https://www.opennet.dev/openforum/vsluhforumID3/120512.html Представлен выпуск сборочного инструментария Qbs 1.16. Это третий выпуск после ухода компании Qt Company от разработки проекта, подготовленный силами сообщества, заинтересованного в продолжении разработки Qbs. Для сборки Qbs в числе зависимостей требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52863<br> https://www.opennet.dev/openforum/vsluhforumID3/120512.html#35 Mon, 04 May 2020 11:40:14 GMT Издевательство над чем?<br>Над сферичным конем в вакууме?<br><br>Вот создатели CMake нагло поиздевались над языками программирования, ради сборки проектов на которых, какбы все это создавалось.<br><br>А над чем у вас будет издеваться Java? особенно в переводе на Kotlin, если можно сделать так, что вся JVM и останется только в среде разработке, а в продакшн уйдут чистые бинари (или теперь даже байт-код на другие VM, отличные от JVM, если не устраивает).<br><br>Даже при всех недостатках Java, которые можно себе нафантазировать (а обычно это именно фантазии и байки, см. ниже) - сборка на Gradle, даже при всех недостатках и его тоже - по-любому получается "меньшим из зол" по сравнению с CMake.<br><br>Это я говорю, как начинавший с C/C++, и долго его изучавший, кому тоже не нравилась когда-то Java по сравнению с C++, говорю:<br>- времена изменились!<br>- Java сильно исправилась (и по времени эти исправления "случайно" совпали с выходом новых стандартов 11+ самого C++).<br><br>Да, у Java был долгий путь развития, однако это уже прошлое.<br><br> https://www.opennet.dev/openforum/vsluhforumID3/120512.html#34 Mon, 04 May 2020 10:56:38 GMT Вам не нужны типы - тогда Питон для вас самое то. Никто не спорит.<br><br>А есть такие люди, которым нужны типы, И, одновременно им нужно собирать проекты.<br><br>А также если этим людям не проблема изучать статически-типизированные языки - то для них системы сборки с типами, встроенными прямо в сборочный DSL - тоже самое то.<br><br>Каждому свое. По способностям и по возможностям к освоению.<br><br>C++ ни разу не хоронят, особенно после стандартов 11+, он живее всех живых. Просто он придерживается классической схемы, когда компилятор отдельно, а тулсеты, включая пакетные менеджеры - отдельно. И не встроены в язык, как объекты первого класса, потому что фишка C++ - это филигранное управление памятью с одновременным высоким уровнем абстрактных типов данных.<br><br>Да, у C++ появилось много достойных конкурентов, даже Java подтянули, до уровня "нескучности", хоть и оставив многословность, ну, это как раз и исправляет Kotlin.<br><br>А тут еще даже Haskell активно пробивается в "промышленность" из "академичности"...<br><br>А еще потребности https://www.opennet.dev/openforum/vsluhforumID3/120512.html#33 Mon, 04 May 2020 07:08:48 GMT cmake неугоден:<br> - синтаксисом,<br> - набором инструментария (FindLibrary)<br> - сложностью написания и анализа сборочны сценариев<br> https://www.opennet.dev/openforum/vsluhforumID3/120512.html#32 Mon, 04 May 2020 07:07:37 GMT Чем лучше месона? Ссылка есть, а то не нагуглить это<br> https://www.opennet.dev/openforum/vsluhforumID3/120512.html#31 Mon, 04 May 2020 06:34:01 GMT Как ты её отвязывать собирался? С собой половину Qt таскать?<br> https://www.opennet.dev/openforum/vsluhforumID3/120512.html#30 Sun, 03 May 2020 22:25:29 GMT Мне не типы нужны, мне проекты собирать :)<br>Развитый синтаксис - много времени на изучение, вон кресты себя активно хоронят: скоро старые спецы помрут а новые не пидут, потому что учится 3-5 лет чтобы получать столько же сколько те кто учился языкам по проще за пол года смысла нет.<br> https://www.opennet.dev/openforum/vsluhforumID3/120512.html#29 Sun, 03 May 2020 22:22:15 GMT Там ещё libuv и ещё штук 5+ портов ставится на фре.<br>Но да, сам цмейк собирается дольше остальных. Заметно дольше.<br><br>Я ничего не знаю про то что вы описываете, я подобные сборочные системы скорее всего не встречал в тех портах которыми пользуюсь.<br>Самое экзотическая система сборки которую видел - waf - какая то фигня на питоне, вроде.<br><br>В общем я пока смотрю на месон и пытаюсь понять: стоит ли на него сваливать с цмейка в своих перснальных проектах.<br>Как вариант я могу иметь обе системы, но хотелось бы понять перспективы.<br> https://www.opennet.dev/openforum/vsluhforumID3/120512.html#28 Sun, 03 May 2020 22:15:23 GMT Ну это можно писать тому кто не видел месона и ничего с ним не делал.<br><br>Как сборщик - я как раз вижу что месон требует меньше зависимостей прежде чем он станет рабочим в системе.<br>Как программист - учить Cmake с его самобытным синтаксисом или месон с питоноподобным - последнее кажется более перспективным.<br>Хотя я лично очень плохо воспринимаю ихние пробелы и pep8 (к месону пока не относится).<br><br>Но мне приходится колупатся в опенсорсных проектах и с месоном и цмейком, при этом на месоне почему то мне или вообще не приходится ничего делать (наверное пока не так распространёт) или там сразу всё очень компактно и понятно (опять же может мне просто везло).<br>На цмейк это часто какие то простыни откровенного говнокода.<br><br>Не знаю, может быть все сборочные системы обречены скатыватся в УГ и становится на вид как автотулс, и цмейк просто старше и ближе а месон ещё только в начале пути.<br><br><br>И лично мои проекты были уже на автотулс, и я смигрировал их на цмейк.<br>И меня смущает обилие зависимостей цмейк на фоне мезона https://www.opennet.dev/openforum/vsluhforumID3/120512.html#27 Sun, 03 May 2020 11:12:13 GMT Поставьте  Qbs в хомяк вместе с библиотеками, делов-то. Требование "использовать системную Qt" достаточно странное, не все диcтрибы имеют свежую Qt.<br>