| |
| |
| 3.3, Аноним (-), 12:23, 09/12/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
2 года уже нормально работают. В kubuntu 16.04 LTS, по крайне мере.
| | |
| 3.6, Аноним (-), 13:05, 09/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Собранные из ebuild'ов полностью работают, как это для вас не странно.
| | |
| |
| |
| 5.13, Аноним (-), 16:11, 09/12/2017 [^] [^^] [^^^] [ответить]
| +7 +/– |
- доктор, у меня болит нога, что посоветуете?
- ХЗ, у меня тоже есть нога, и она не болит... ЧЯДНТ?!
| | |
| |
| 6.25, Аноним (-), 22:32, 09/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
И вот поэтому я буду всем здоровым говорить, что у них тоже болит нога, а они глупые не верят.
| | |
|
|
|
|
|
| 1.4, anonymous (??), 12:39, 09/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
>В отличие от qmake, Qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов
Вот зачем эту мантру повторять? 1. qbs зависит от Qt; 2. qmake может собрать любой проект.
| | |
| |
| 2.5, Аноним (-), 13:02, 09/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Догадываюсь, что к моменту полной стабилизации кодовой базы, они добавят урезанный движок QML прямо в сам проект. И можно будет его устанавливать на сервере без Qt-модулей.
| | |
| |
| 3.7, anonymous (??), 13:09, 09/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Движок QML зависит от QtCore и QtGui. Никто в здравом уме не будет их тащить с собой. А так на сервере собирай хоть сейчас, ничто этому не мешает.
| | |
|
| 2.14, fff (??), 17:06, 09/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 1) Одним qbs-ом можно собрать проект под разные версии Кути
2) Одним qmake-ом ты можеш собрать только проект с одной конкретной версией Кути
| | |
| |
| 3.30, anonymous (??), 13:49, 10/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
> 1) Одним qbs-ом можно собрать проект под разные версии Кути
> 2) Одним qmake-ом ты можеш собрать только проект с одной конкретной версией
> Кути
Про обратную совместимость не в курсе, конечно.
| | |
|
|
| 1.8, Дуплик (ok), 14:05, 09/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 Зависит от JavaScript'а, QtQuick'а и Qt'а. Ну и зачем такое счастье? Тогда уж проще взять Gradle, тот что на Java. Он как минимум легковеснее и функциональнее.
И да, QBS точно так же, как make, опирается на дату изменения файла, а не на его хеш/отпечаток. Поэтому наследует проблемы своего предшественника.
Нисколько не удивительно, что он не вылез из экосистемы Qt'а ни на йоту. Да и в самой экосистеме имеет шаткое положение -- год другой и можно будет выкидывать, как уже выкинули QtScript, QtWebkit.
Напоминаю, что Qt и хотя бы его примеры так до сих пор и не перевели на QBS, хотя планы были грандиозные.
| | |
| |
| 2.10, Аноним (-), 15:19, 09/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Так к 6 же переведут.
QtScript выкинули в пользу QtQuick.
QtWebKit выкинули из-за стагнации в апстриме.
| | |
| |
| |
| 4.20, Аноним (-), 20:47, 09/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Нет. Разработчики сказали что QtQuick предпочтителен в долгосрочной перспективе и все усилия будут направлены на его развитие, чтобы он по возможностям догнал и перегнал QtWidgets. В QtWidgets нельзя по быстрому добавить свистоперделки, появившиеся в Win8 и Android, поэтому решили его (и себя) не калечить и сделать что-то новое. Но программисты вполне могут использовать QtWidgets, который помечен как законченный (доделанный).
| | |
|
| 3.41, name (??), 14:02, 13/12/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>>QtWebKit выкинули из-за стагнации в апстриме.
QtWebKit вполне себе развивается, а ядро WebKit - тем более. Просто в Qt нет ресурсов чтобы поддерживать и QtWebKit и QWebEngine (а делают это одни и те же люди), поэтому QtWebKit был удалён.
| | |
|
| 2.40, dontletsmac (?), 10:46, 13/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>тот что на Java. Он как минимум легковеснее
На Java легковеснее? Видимо, Дуплик зависит от каких-то веществ.
| | |
|
| 1.16, Alex (??), 18:34, 09/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Зачем этот бардак они опять плодят??? неужели трудно взять и юзать cmake и не парится по поводу привязки? Он более гибкий чем этот qmake и более функциональный. Так они еще один бред придумали.
| | |
| |
| 2.17, Аноним2 (?), 19:14, 09/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Так они все к своему фрэймворку привязывают, чтобы к конкурентам не бежали. Некоторым нравятся комбайны все в одном. Нормальные тактические ходы.
| | |
| |
| 3.18, Аноним (-), 20:28, 09/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Звучит примерно так: производитель комбайнов выпустил новый набор гаечных ключей, чтобы таким образом привязать фермеров к своему изделию и не дать им перейти к производителям ручных косилок и молотилок. Но по какой-то неведомой причине фермерам нравятся комбайны, а не ручные косилки/молотилки. Это заговор чистой воды.
| | |
| |
| 4.22, Аноним (-), 21:44, 09/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
производитель комбанов решил перейти со старых вендорлочных гаечных ключей, к которым привыкли, на новые вендорлочные гаечные ключи, к которым страдальцы старого вендорлока опять должны привыкать, а стандартные ключи производитель комбайнов не желает использовать, ибо вендорлок это деньги
| | |
| |
| 5.24, Аноним (-), 22:13, 09/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если ключей от газонокосилки не хватает чтобы починить комбайн, то виноват конечно комбайн. Ну а чтобы построить ракету тем более не нужно ничего нового придумывать, вполне должно хватить ключей от газонокосилки, иначе это будет злой вендорлок.
| | |
|
|
|
| 2.21, Хренонимус (?), 21:43, 09/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Удобная система сборки - это хорошо.
CMake, сколь бы ни был популярным, удобным не является.
Чего стоит только лиспоподобный внутренний язык. JS, что в QML, какой-никакой язык общего назначения.
| | |
| |
| |
| 4.26, Хренонимус (?), 00:59, 10/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
А зачем в системе сборки нужен эзотерический язык, который придётся осваивать, вместо того чтобы быстро настроить сценарии сборки, используя привычную логику?
Это либо должна быть чрезвычайно простая унифицированная система, как pip/go get/cargo, либо нечто расширяемое, но с вменяемым и простым языком.
| | |
| |
| 5.34, Аноним (-), 13:20, 11/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да затем, что не всем привычна логика JS (или python, или что там ещё сейчас модно в сборочницы пихать), а изучить с нуля простенький DSL намного легче.
| | |
| |
| 6.43, Аноним (-), 02:23, 20/12/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> а изучить с нуля простенький DSL намного легче
это сначала так кажется. а когда тебе придется перелопачивать тонны г-кода на этом простеньком DSL при практически полном отстуствии средств разработки и отладки, то хочется взять и у*бать тому, кто это язычок породил на свет
| | |
|
| 5.35, Аноним (-), 13:23, 11/12/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Это либо должна быть чрезвычайно простая унифицированная система, как pip/go get/cargo,
И что из перечисленного является сборочной системой?
| | |
|
|
| 3.31, anonymous (??), 13:51, 10/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>CMake, сколь бы ни был популярным, удобным не является.
Ты просто его не осилил. Он прост, как топор.
| | |
|
|
| 1.32, nc (ok), 15:15, 10/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Хорошо что развивается, это в любом случае лучше чем makefile
Но если в целом - то зачем вообще нужны сценарии и правила сборки? Описание проекта должно быть ДЕКЛАРАТИВНЫМ, а не представлять собой еще один язык императивного прорграммирования. То есть - список файлов исходников, параметры проекта (начиная от имени и заканчивая опциями оптимизации и кодогенерации), список внешних библиотек... все это по сути своей декларативная информация, то есть json или xml бы тут подошел лучше чем любой язык программирования. Исключения в виде запуска внешних программ для обработки чего-либо в процессе сборки должны оформляться как декларативные ноды специального типа, в которых прописывается внешняя программа и ее аргументы.
| | |
| |
| 2.38, Аноним (-), 15:27, 11/12/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Так в Qbs так и есть же. И декларативность, и даже json. И исключения в виде запуска внешних программ. Но запуск внешних програм реализован довольно неудобно, по мне так. Так что если у вас нестандартная процедура сборки, требующая запуска многих внешних программ - ИМХО лучше использовать что-то другое, например тот же CMake. А если сборка стандартная - то Qbs удобнее, декларативнее и красивее.
| | |
| |
| 3.39, Владимир (??), 07:39, 12/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
 ну я с вами не соглашусь, я еще в пору qbs 0.6-0.7 сборку на паскале прикручивал. Не могу сказать что это сделать сложнее чем в cmake.
| | |
|
|
| 1.33, Анонимы (?), 17:26, 10/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Так и не понял, чем им qmake не угодил. И кому этот qbs будет нужен в остальных проектах, при наличии и так не малого зоопарка.
| | |
| |
| 2.42, name (??), 14:04, 13/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
+1. До сих пор им никто не пользуется. Если кто-то начинает новый проект, то это или cmake или qmake.
| | |
|
|
