| 1.5, QwertyReg (ok), 10:20, 14/10/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –16 +/– |
 Правильно, нужно распылять силы сообщества на поддержку устаревшего легаси. Сначала Xorg, потом Devuan, теперь протухший QBS будем накрашивать и одевать в костюмчик, как будто бы он живой.
| | |
| |
| 2.6, sweetlao (?), 11:32, 14/10/2021 [^] [^^] [^^^] [ответить]
| +3 +/– |
Уж лучше легаси, чем экспериментальные корпоративные игрушки, на которые у них денег жалко- хотят чтоб бесплатно сделали, вот и нанимают всяких Лёнек, да Дрюшек по объявлению за мелкий прайс.
| | |
| 2.8, Аноним (8), 13:45, 14/10/2021 [^] [^^] [^^^] [ответить]
| +4 +/– |
ты последний, кого сообщество будет спрашивать, как ему управлять своими силами
| | |
| 2.22, Аноним (22), 18:43, 15/10/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> теперь протухший QBS будем накрашивать и одевать в костюмчик, как будто бы он живой.
Э... Тролинг?
Лучше QBS еще никто ничего не сделал.
У QBS была одна проблема.
Для того, что бы его собрать - нужен Qt.
А Qt-никам нужна система сборки для сборки самого Qt.
Циклическая зависимость получилась. Ошибка менеджеров на этапе постановки задачи.
| | |
| |
| 3.23, Аноним (23), 02:19, 18/10/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> У QBS была одна проблема. Для того, что бы его собрать - нужен Qt.
Ещё в Qbs крайне неудобно выполнять свои команды. Надо создать массив на яваскрипте, засунуть в этот массив имя команды и все её аргументы как отдельные элементы массива, и передать массив в специальную функцию. В то время как в Make и CMake можно писать команду и её аргументы в строчку через пробелы, как в шелле.
> Циклическая зависимость
Это как раз не проблема. Для сборки компилятора С тоже нужен компилятор С. Для сборки линкера нужен линкер. Для сборки GNU Make и CMake тоже они сами нужны.
| | |
| |
| 4.24, Аноним (22), 13:06, 18/10/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> В то время как в Make и CMake можно писать команду и её аргументы в строчку через пробелы, как в шелле.
За это получаешь возможность контроля выполнения задачи.
> Это как раз не проблема. Для сборки компилятора С тоже нужен компилятор С. Для сборки линкера нужен линкер. Для сборки GNU Make и CMake тоже они сами нужны.
Как бы Qt'ники как раз и сказали, что это основная проблема.
C, make и cmake являются самыми распространеными инструментами. Так что требовать их наличие - нормально.
Qt-ники играют вдолгую. Как пример, через пару десятков лет скорее всего C, make и cmake будут. И с очень высокой долей вероятности совместимость особо поломана не будет. А вот бинарник qbs, скорее всего не запустится.
| | |
|
|
|
| 1.17, Anonymous XE (?), 18:12, 14/10/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Обновлён и портирован на C++17 модуль QtScript, который больше не поставляется в Qt 6 и теперь входит в состав Qbs.
Т.е., есть надежда, что в последующем они всё, что нужно для Qbs, реализуют у себя и не будут зависеть от Qt.
| | |
| |
| |
| 3.20, Аноним (20), 21:49, 14/10/2021 [^] [^^] [^^^] [ответить]
| +/– |
 такого плана не было, если не считать первоапрельского ишью, в котором еще и на хаскель предлагали переписать.
| | |
|
| 2.21, Enamel (ok), 00:02, 15/10/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Что плохого в зависимости от Qt?
Не хуже, чем зависеть от STL.
| | |
| |
| 3.25, adolfus (ok), 23:17, 22/10/2021 [^] [^^] [^^^] [ответить]
| +/– |
 STL -- это часть стандарта языка С++, а Qt -- непонятное што. Сегодня так, а завтра эдак.
Иди собери 10-летней давности проект, который использует Qt-классы. А с STL нет никаких проблем -- я использую без каких-либо коррекций код, написанный в конце 90-х под C++98. Раз в пару лет пересобираю довольно большой проект и еще ни разу не наткнулся на проблемы именно с STL. А с Qt-классами проблемы возникают с каждой новой версией и всякий раз нужно конкретно разбираться, корректировать код, программную документацию, испытания и прочая волокита.
Что касается gui, то тут просто техническая задница -- проект, изначально написанный с qt3, с грехом пополам удалось отмигрировать на qt4, но на qt5 уже не получилось, поскольку нужно было сохранить функционал и пользовательский интерфейс, включая отзывчивость на консольные события, неизменными. Добиться UI-совместимости не удалось даже в малом. В итоге были вынуждены переписать междумордие на Tcl/Tk.
| | |
|
|
|
