Deprecation of Qbs

[Авварон]

Лучше бы помогли котрибутить в qbs чем питон обсуждать)

[kuzulis]

Мнда.. кажется в QMake совсем плохо с iOS && XCode: https://bugreports.qt.io/browse/QTBUG-71566

И как, вы любители QMake ответите на это?

Кстати, как там с Android/iOS на CMake? Жизнь есть?

[Авварон]

Ой я как раз вчера видел багрепорт на кумейк, иос, пришники и статические плагины. Тоже поржал..

[kambala]

Мнда.. кажется в QMake совсем плохо с iOS && XCode: https://bugreports.qt.io/browse/QTBUG-71566

И как, вы любители QMake ответите на это?

под QtQuick нормально генерирует... (но в 5.11 не пробовал)

[Igors]

Мнда.. кажется в QMake совсем плохо с iOS && XCode: https://bugreports.qt.io/browse/QTBUG-71566

С Xcode да, хреновато. Проект он (qmake) создает, но дальше шаг влево/вправо - и проект калечный. Приспособился так: нужен новый moc - добавляю руками скрипт. Хотя не исключено что мой Xcode слишком стар, или я просто "не разобрался".

По поводу CMake - ну если либа с ним идет (а так идут многие), то выбора собсно и нет - надо юзать CMake. Спасибо хоть какое-то UI дали. Потыкав опции туда-сюда удается получить проект и забыть эту унылую процедуру до следующего раза. Ожидать что будет qmake или qbs не приходится.

А вообще такая любовь к "сборке" выглядит очень подозрительно 

[kuzulis]

Kampala,
И где оно (Кумэйк) нормально генерит зависимости? Например, если в проекте есть статик либы которые должны быть скомпилены и прилинкованы к екзешке. Не верю что оно работает. Пример в студию (Имею ввиду для хкода и иос)!

Igors,
а причём тут мок? И юзал ли кто Смэйк для генерации нормального  Хкод проекта для иОс? Десктоп варианты меня не интересуют, там все более менее норм.

[kambala]

Kampala,
И где оно (Кумэйк) нормально генерит зависимости? Например, если в проекте есть статик либы которые должны быть скомпилены и прилинкованы к екзешке. Не верю что оно работает. Пример в студию (Имею ввиду для хкода и иос)!

а, так речь конкретно о зависимостях/плагинах? такое не пробовал. Мне показалось, речь идет о генерации проекта в общем

в качестве обходного пути можно попробовать так: сгенерировать Xcode-проекты для приложения без зависимостей и для каждого плагина, а после руками драгндропнуть проекты плагинов в проект приложения — они должны добавиться в зависимости к таргету приложения.

[kuzulis]

В общем, в баг трекере ответили что они не будут ничего делать для обработки под-проектов в QMake при генерации XCode проектов... Советуют все либы/плагины сначала собирать в QtCreator (при помощи Make), а потом открыть XCode и линковать их (уже готовые либы) с приложением. Гыыы...

Как вам такое, QMake филлы?


PS: Что-то тенденции удручают. Qt-шники говнюки еще те..

[Авварон]

В общем, в баг трекере ответили что они не будут ничего делать для обработки под-проектов в QMake при генерации XCode проектов... Советуют все либы/плагины сначала собирать в QtCreator (при помощи Make), а потом открыть XCode и линковать их (уже готовые либы) с приложением. Гыыы...

Как вам такое, QMake филлы?


PS: Что-то тенденции удручают. Qt-шники говнюки еще те..

Вроде они наняли нового "эффективного менеджера"

[Авварон]

Какое же говно этот ваш qmake. PWD возвращает путь в сорцах содержащий pri-файл. А OUT_PWD возвращает путь для pro-файла, который включает этот pri-файл (!). А симметричная OUT_PWD для сорцов переменная называется _PRO_FILE_PWD_
Fuck you, logic.

[zhbr]

Какое же говно этот ваш qmake. PWD возвращает путь в сорцах содержащий pri-файл. А OUT_PWD возвращает путь для pro-файла, который включает этот pri-файл (!). А симметричная OUT_PWD для сорцов переменная называется _PRO_FILE_PWD_
Fuck you, logic.

PWD - директория в которой лежит текущий обрабатываемый файл - это может быть и pri и pro взависимости от того где используется эта переменная.
OUT_PWD - директория в которой лежит Makefile для текущего обрабатываемого файла.
_PRO_FILE_PWD_ - директория в которой лежит текущий pro(не pri).

[ViTech]

Вот и эффективный менеджер высказался:

I’d like to bring Qt product management (PM) view to the discussion. There has been much more behind the decision making than the customer survey, which is frequently mentioned in the comments.
One of the PM tasks is to visit Qt customers to understand what customers want and need to run their business, based on Qt. In numerous customer meetings, we heard that customers prefer having a good support for their existing SW projects/products. Majority of customers mentioned that seamless integration to their CMake projects is more important than a custom build system.
After listening to our customers’ voice, we turned into the community. Some of you may remember the Qbs usage survey, I conducted in Qbs mailing list in June. I asked in which kind of projects developers use Qbs. The survey did not get a lot of interest, as only 13 projects were reported, 4 pet projects and 9 real projects. Qbs was considered superior to many other build systems in terms of performance, scalability, syntax, but there were also concerns about missing features, such as CMake generators, embedded toolchain support and so on. The PM did not make a conclusion that Qbs is not used much, but rather we were more convinced that Qbs is not mature. Serious development effort would be needed to make it ready or we could use the effort to build support for another build system.
I hope this will comment would help understanding the decision from the product management point of view.

Короче, "Qbs is not mature", вот и вся недолга .

[kuzulis]

Смешное в том, что ничего так и не довели до ума.

1. qmake уже не собираются особо исправлять (особенно Андройд + иОС), т.к. запланировали "ударную пятилетку" перехода на cmake.
2. qbs задепрекейтили.
3. cmake еще не готово (от слова совсем), и будет ли готово в ближайшее время (особенно Андройд + иОС) - неизвестно (как говорят - трындеть - не мешки ворочать).

И на данный момент получается ни-то ни-сЁ. Все в каком-то подвешенном состоянии. И как, нам, пользователям быть - тоже непонятно.