The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Выпуск сборочного инструментария Qbs 1.17"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск сборочного инструментария Qbs 1.17"  +/
Сообщение от opennews (??), 14-Сен-20, 12:11 
Представлен выпуск сборочного инструментария Qbs 1.17. Это четвёртый выпуск после ухода компании Qt Company от разработки проекта, подготовленный силами сообщества, заинтересованного в продолжении разработки Qbs. Для сборки Qbs в числе  зависимостей требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53709

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 14-Сен-20, 12:11   –6 +/
зачем ?
ведь есть cmake
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #7, #48

2. Сообщение от Odalist (?), 14-Сен-20, 12:17   +10 +/
Пусть будут альтернативы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5, #12

3. Сообщение от Аноним (3), 14-Сен-20, 12:25   +2 +/
затем, что есть CMake
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #26

4. Сообщение от uytuyt (?), 14-Сен-20, 13:33   +1 +/
эх, зоопарк билдовых систем...

понадобилось как-то построить tcmalloc на системе, на которой нет рутового доступа - это такое приключение, что захотелось пристрелить того, кто эти зоопарки разводит :)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #8

5. Сообщение от Аноним (5), 14-Сен-20, 14:23   –4 +/
Правильно, пусть вокруг тебя говорят кроме русского на китайском и африкаансе, так хорошо иметь альтернативы русскому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

6. Сообщение от Аноним (5), 14-Сен-20, 14:28   –3 +/
Нет зоопарка, все сейчас на CMake. А маргиналы-отщепенцы всегда были, есть и будут, только они погоды не делают, и даже ничего полезного не производят

> понадобилось как-то построить tcmalloc на системе, на которой нет рутового доступа - это такое приключение, что захотелось пристрелить того, кто эти зоопарки разводит :)

А проблема-то только в вашем невежестве. Есть и кучи готовых пакетных систем, и готовые бинарные пакеты, и кросскомпиляция, да и руками её собрать очень просто - и всё это не требует рута и делается одной -друмя командами.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #10, #11

7. Сообщение от Денис (??), 14-Сен-20, 14:39   +/
> cmake

А как узнать все доступные опции с описанием? Наподобие ./configure --help

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13

8. Сообщение от Денис (??), 14-Сен-20, 14:42   +1 +/
Зоопарк это хорошо.

Для сборки не нужны рутовые права. Только для установки. По умолчанию /usr/local. Но можно указать в configure другой prefix, например ~/.local

Мне Cmake не нравится. Потому что я не знаю где в нем все доступные опции искать, как в ./configure.

Cmake популярен. Но еще meson (python) с ninja используют.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

9. Сообщение от Аноним (9), 14-Сен-20, 14:47   +3 +/
Хорошо бы было, если бы русскому была только одна альтернатива - Эсперанто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #35

10. Сообщение от Аноним (12), 14-Сен-20, 14:47   +3 +/
> все сейчас на CMake

пользователи Meson в курсе?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

11. Сообщение от Авваронemail (??), 14-Сен-20, 14:48   +1 +/
Ну, "все" - это громко сказано - Яндекс слез с CMake несколько лет назад (я застал период когда файлы еще назывались CMakeLists.txt но уже собирались через ya-make), Facebook сидит на buck, Google (вроде бы) на Meson.
Опенсосрс, может, и сидит на cmake, но он до того на автотулзах сидел что, конечно, огромный шаг для человечества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #21, #38

12. Сообщение от Аноним (12), 14-Сен-20, 14:50   +/
только же не прибитые гвоздями к Qt.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #14, #17, #41

13. Сообщение от Аноним (13), 14-Сен-20, 15:29   +/
"cmake -LH" ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #23

14. Сообщение от Авваронemail (??), 14-Сен-20, 16:09   +/
Какая разница что оно тянет за собой? Cmake так-то собирается слегка дольше чем Qbs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15

15. Сообщение от Аноним (12), 14-Сен-20, 16:30   –1 +/
разница, что C, C++ доступны на большем числе платформ, чем они же + Qt.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #16, #27

16. Сообщение от Авваронemail (??), 14-Сен-20, 16:43   +/
Вы часто собираете софт на платформах где нет Qt?
Или все-таки используете венду\линукс и кросс компиляцию?
Так-то Qt на айфон есть, а компилятор туда не завезли, потому что кто будет собирать что-то на айфоне?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #18

17. Сообщение от Аноним (9), 14-Сен-20, 17:01   +/
Думаю, если не забросят проект, то со временем запилят минимально необходимый автономный интепретатор QML.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

18. Сообщение от Аноним (12), 14-Сен-20, 17:27   +/
Кросс компиляция хорошо, но подходит не всем проектам. Если Qbs претендует быть заменой CMake, Meson, Autotools, Boost.Build, qmake и т.д., ему бы неплохо тоже научиться бутстрапиться на платформах, которые поддерживают эти системы сборки.
Напомнить, почему Qbs не стал системой сборки для Qt 6? Минимум не прошел по 2.а, 3.а Требований [1]. Так он и не пройдет, пока не избавится зависимости от Qt.

P.S.: Qt 6 дропнул QtScript. Уже решили, чем его будут заменять в Qbs?

1. https://lists.qt-project.org/pipermail/development/2018-July...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #19, #20

19. Сообщение от Авваронemail (??), 14-Сен-20, 18:08   +1 +/
Qbs не стал системой сборки для Qt6 потому что у Qt Company хреновый менеджмент, который не в состоянии обеспечить прибыль. 2018й год - 2 миллиона убытков https://investors.qt.io/financials/ (2я вкладка)
С такими показателями все непрофильные проекты срезаются. Ну нет у них денег пилить свою систему сборки, сорян. У Kitware есть, а у QtCompany - нет, shit happens.
Для того, чтобы бутстрапить Qbs не надо слезать с Qt, погуглите что такое бутстрап. Спойлер - configure скрипт в Qt собирает (собирал) небольшую версию QtCore которой достаточно, чтобы собрать qmake и уже им конфигурил проект.
Примерно то же самое делает cmake с собой АФАИК.
Аргументы Тьяго высосаны во многом из пальца, если вложить то количество человеко-часов которое они потратили на CMake порт в Qbs все эти проблемы были бы решены (кстати, порт Qt на Qbs в альфа-версии был задоолго до CMake). Но последнее время над Qbs работал 1 (прописью - один) человек, над портом на CMake работают десятки людей.
Далее, Qbs уже несколько лет таскает форк QtScript и никакой проблемы собрать с ним нет - сборка регулярно проверяется. Сам QtScript надо минимально пропатчить чтобы собрать с qt6 - я проверял.
Далее, активно пилится порт на QtQml https://codereview.qt-project.org/c/qbs/qbs/+/302178
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #24, #43

20. Сообщение от Авваронemail (??), 14-Сен-20, 18:10   +/
Да, можно еще список таких платформ, где есть cmake но нет Qt?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #25

21. Сообщение от анонимтвоюмать (?), 14-Сен-20, 18:16   +/
Google точно не на bazel?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #22

22. Сообщение от Авваронemail (??), 14-Сен-20, 18:40   +/
Я путаю bazel и meson, так что вполне возможно=) Я потому и написал в скобках что вроде бы.
Вики говорит что bazel https://en.wikipedia.org/wiki/Bazel_(software)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

23. Сообщение от Денис (??), 14-Сен-20, 19:09   +/
Благодарю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

24. Сообщение от Аноним (12), 14-Сен-20, 19:41   +/
Хреновый менеджмент виноват в том, что многие Пользователи Qt злоупотребляют их лицензией и не платят за коммерческое использование. О чем говорили в том обсуждении позднее. Но это все нетехнические вопросы, оставим для другого случая. На тот момент Qbs по функционалу уже рассматривали как кандидата на систему сборки Qt 6. Мейнтейнеров тоже нашли бы, как нашли их для переезда на CMake.
Там же в обсуждении никто не ставил под сомнение Требования Тьяго. Нет смысла тянуть систему сборки, которая не пользуется популярностью сообщества. Можна спорить, почему не пользуется популярностью, но одна из причин - мало кому интересно тянуть прицепом зависимость от Qt в проекты, которые про этот Qt и не слышали. Об этот говорили в том числе в предыдущих обсуждениях релизов Qbs на opennet.
Под бутстрапить понимал подготовить систему сборки из исходного кода пользуять только интерпретатором и/или компилятором. Напишите явно, в чем ошибка, спасибо. Сначала в код Qbs надо перенести функционал небольшой версии QtCore, QtScript, QtQml и т.д., что бы для сборки было достаточно только компилятора C, C++. Тогда можно будет говорить, что он догнал CMake по портируемости и может составлять ему конкуренцию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #30

25. Сообщение от Аноним (12), 14-Сен-20, 19:54   –1 +/
Те, что дропнули с релизом Qt 6 и не планируют возвращать, например. Да и вляд ли у cmake и Qt одинаково с переносимостью, с учетом разници в числе зависимостей и объеме кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

26. Сообщение от Аноним (26), 14-Сен-20, 19:57   +2 +/
зачем нужна еда, если можно есть говно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

27. Сообщение от Аноним (27), 14-Сен-20, 20:14   +/
> C, C++ доступны на большем числе платформ, чем они же + Qt.

Qt и qbs тебе потребуются там где сборка идёт (на host- и build-системе), а не там где будешь запускать собранную программу (target-система). Использовал qbs для сборки под stm32, но все же в qmake получается проще (костылей в qmake требуется больше, но управляться с этими костылями потом легче).

Очевидно, что Qt под stm32 для таких экспериментов собирать не нужно ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #29, #42

28. Сообщение от Аноним (28), 14-Сен-20, 20:15   +/
Чем лучше meson?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

29. Сообщение от Аноним (12), 14-Сен-20, 20:23   +/
повторюсь, кросс компиляция подходит не для всех проектов. например, она не поможет, если нужный инструментарий есть только на целевой платформе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #40

30. Сообщение от ABBAPOH (ok), 14-Сен-20, 22:50   +2 +/
> Хреновый менеджмент виноват в том, что многие Пользователи Qt злоупотребляют их лицензией

Ну вы понимаете, есть куча компаний, который зарабатывают на Qt продавая, скажем, консалтинг. Например KDAB или Woboq. Что-то у них не возникает проблема со злоупотреблением юзерами. Если ваша бизнес модель не работает потому что юзеры какие-то не такие - плохие не юзеры, а ваша бизнес модель (и, как следствие, менеджмент, который эту модель продвигает). Не продаются лицензии? Продавайте консалтинг или поддержку. Лицензирование Qt настолько непрозрачно и криво устроено, что неудивительно, что в этом никто не хочет разбираться.

> Мейнтейнеров тоже нашли бы, как нашли их для переезда на CMake.

Но ведь не нашли. Еще раз, последние несколько лет в Qbs не инвертировалось от слова совсем. Я уже после перехода в опенсорс добавлял поддержку clang-cl или там protobuf запилил. Что мешало сделать кутешникам? Ах да, примерно нулевой manpower на проекте. Серьезно, небольшая команда опенсорса делает для проекта больше чем делала QtCompany.

> Там же в обсуждении никто не ставил

Ну вообще-то возмущения было много. Вообще, Тьяго в последнее время много глупостей пишет (например его "аргументация" про QVector), а его Требования были составлены так что под них подходил только CMake. Я тоже так могу - декларативный синтаксис, поддержка иОС из коробки, поддержка PCH на линуксе, раздельная дебаг инфа - всего этого не было на момент написания Требований. Чего-то нет и сейчас, тикет вон до сих пор открыт https://gitlab.kitware.com/cmake/cmake/-/issues/20256. Но да, это "зрелая" система сборки, на дворе 2к20й, dsymutil до сих пор не поддерживается - кому этот ваш Мак нужен, правда?

Дело не в том что Qbs или CMake плохой или хороший, просто нельзя вытащить такой проект силами одного человека. Просто QtCompany это коммерчески не выгодно, ШТОШ, бывает.

> Напишите явно, в чем ошибка, спасибо

Ни в чем не ошибка, просто аноним выше (или это были вы?) путает бутстрап и поддержку разных платформ. Единственное (!) зачем нужен бутстрап - это для сборки всяких дистрибутивов Линукса - там принято чтобы не было кросс-зависимостей (и Тьяго почему-то фокусировался на этом "забыв" про остальные платформы). На маке и венде никакой проблемы собрать Qbs тем же cmake'ом или предыдущей версией Qbs/предыдущей версией Qt и уже им собирать Qt.
Поддержка же различных платформ абсолютно ортогональна теме бутстрапа. Вам нужен сам факт наличия Qt на этой платформе, а бутстрап не нужен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #31, #32

31. Сообщение от Qbs_king (?), 14-Сен-20, 23:39   +/
А что такого Тиаго сказал про QVector? Где это можно поискать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #33

32. Сообщение от Аноним (12), 15-Сен-20, 01:23   +/
> Но ведь не нашли. Еще раз, последние несколько лет в Qbs не инвертировалось от слова совсем.

Мы же говорим по состоянию на июль-октябрь 2018, когда решалось с системой сборки Qt 6? На протяжении двух лет до этого значительная, если не большая часть комитов была от ментейнеров Qbs. Внимания было недостаточно, время выделяли по остаточному принципу, но за два года с того момента по сейчас это все можно было догнать. Никто же не тогда говорил:"в Qbs нет такого то функционала, неизвестно как и за сколько реализовать, поэтому переезжаем на CMake". Qbs зарубили, потому как не соответствовал Требованиям. А когда решилось, что Qt 6 переезжает на CMake, понятно уже не тратили ресурсы на Qbs.

> Ну вообще-то возмущения было много

Возмущение было у Пользователей:"как можно дропать Qbs, когда мы им пользуемся на своих проектах". Мейнтейнеры от Qt закусили удила. Но AFAIR никто не сказал, что Требования нерелевантны.

> Требования были составлены так что под них подходил только CMake

Meson им соответствовал по всем пунктам. Тьяго это косвенно подтвердил [1]. Там стал вопрос, что кому то от Meson надо было поучаствовать в исследованиях по переезду QtCore на их систему сборки. Желающих не нашлось, в отличие от разработчиков CMake.

> Тьяго в последнее время много глупостей пишет

Думается у Тьяго есть задачи, которые он должен выполнять. А у QtCompany обязательства помогать ему с этим.

> Но да, это "зрелая" система сборки, на дворе 2к20й, dsymutil до сих пор не поддерживается - кому этот ваш Мак нужен, правда?

Не так. Kitware - юридическое лицо, с которым можно заключить договор на поддержку и "пощупать за вымя" (с) если что. А как поступить в случае проблем с Meson? Садить на него людей и допиливать своими силами? Это небыло озвучено в Требованиях, но QtCompany тоже должны были учитывать.

> Просто QtCompany это коммерчески не выгодно

А еще Сообщество Qbs насчитывает 2,5 человека. Не задавались вопросом почему? Как получилось, что система сборки с JS-like синтаксисом и кучей других плюшек проигрывает монстру начала нулевых. Что же могло пойти не так?

> Единственное (!) зачем нужен бутстрап - это для сборки всяких дистрибутивов Линукса

Спорно. Навскидку Autotools и Boost.Build где есть бутстрап, qmake и meson с оговорками. Это удобно, потому как нет проблемы курицы и яйца.

> Поддержка же различных платформ абсолютно ортогональна теме бутстрапа.

Shell, Python, Perl, C, C++ уже есть в каждом утюге. Если системе сборки достаточно их для бутстрапа, это автоматом делает ее кроссплатформенной.

1. https://lists.qt-project.org/pipermail/development/2018-Octo...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #34

33. Сообщение от ABBAPOH (ok), 15-Сен-20, 01:39   +/
Ну там решили сделать поведение QVector::erase не таким как описано в стандарте/на cppref (он ВНЕЗАПНО делает shrink). На мой вопрос "а как так, вот же на cppref написано как оно должно работать" был ответ "cppref нам не указ".
Я бы понял аргументы типа COW виновато, имплементация такая, но нет, им просто захотелось сделать по-другому.
К счастью, вроде бы отменили эти "чудесные" изменения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

34. Сообщение от ABBAPOH (ok), 15-Сен-20, 02:16   +1 +/
> А еще Сообщество Qbs насчитывает 2,5 человека. Не задавались вопросом почему? Как получилось, что система сборки с JS-like синтаксисом и кучей других плюшек проигрывает монстру начала нулевых. Что же могло пойти не так?

Давайте еще вспомним историю MS-DOS.
Qbs не взлетел не потому что он как-то не так написан (он и сейчас быстрее чем CMAKE+ninja и имеет фичи которых в CMake нет до сих пор) а потому что QtCompany не делала для ее продвижения _вообще_ ничего. От слова совсем. Они как в надоевшем меме с Доге что-то мямлили про переход Qt6 на Qbs "но это не точно мы не уверены и вообще непонятно". Я на Qt писал в 14м году потом был перерыв до 2018го и когда я стал изучать как изменилась ситуация выяснил что за 4 года не было сделано НИЧЕГО. Была _одна_ презентация Jake про Qbs и ВСЁ.
Или другой пример - они проводили опрос среди юзеров кто юзает Qbs. Ну опрос и опрос, лично я его проигнорил. А оказывается, на основании этого опроса принималось решение о deprecated - мол юзеров нет. Лол, у меня все проекты на Qbs, теперь я его разрабатываю, но даже я не участвовал в том опросе.
Есть подозрение что каким бы говном CMake не был (а он был говном до недавнего времени), Kitware сумела продать это говно юзерам (им помогло что альтернативой были автотулз, которые еще хуже). Это в общем типичная история успеха - успей выйти в центр рынка, навали там кучу чтобы никто не сунулся, а потом доводи продукт до ума.
Требования Тьяго были написаны в июне, одно из требований было про "2 года крупный проект в дистрибе линукса блабла". В октябре qbs объявляют deprecated. Как же выполнить требование про "2 года блабла" за 3 месяца-то? Я уж молчу что QtCreator собирается с Qbs последние лет 5.
Проблема бутстрапа не является технически неразрешимой, просто это несколько недель унылой работы которая нужна в последнюю очередь. Собственно никто не спорил с этим пунктом потому что он выеденного яйца не стоит - надо просто инвестировать Х человеко-часов (и тут мы возвращаемся к вопросу о деньгах в Qt Company и почему это не сделано за 4 года).
Проблема зависимости от QtScript не является технически неразрешимой - Ричард вполне справляется с портом на QmlEngine. Что мешало это сделать раньше? Ах да, всего 1 человек который тащил весь проект...

> Shell, Python, Perl, C, C++ уже есть в каждом утюге. Если системе сборки достаточно их для бутстрапа, это автоматом делает ее кроссплатформенной.

Помимо бутстрапа вам надо собрать еще ваш код. Если ваш код использует С++17 а у вас только сишный компилятор, то как на перле скрипты не пиши, не выйдет каменный цветок.
Поэтому я, опять же повторюсь, что проблема бутстрапа и проблема поддержки разных систем - две абсолютно ортогональные проблемы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #45

35. Сообщение от Кочегар (ok), 15-Сен-20, 02:34   +1 +/
А в качестве альтернативы Эсперанто пусть будет только Интерлингва, Идо, Оксиденталь и Волапюк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #36

36. Сообщение от Аноним (36), 15-Сен-20, 09:43   +1 +/
Квенья забыл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

37. Сообщение от kuzulisemail (?), 15-Сен-20, 09:43   +/
> Чем лучше meson?

А Вы таки скажите а чем мезон то лучше? Что он умеет кроме GCC, CLNG и MSVC? Он умеет кросс-компилить? Он умеет другие тулчейны? Что он может без питона (только таскать питон с собой)?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

38. Сообщение от Аноним (36), 15-Сен-20, 09:47   +/
>ya-make

вот что-что - а вот-это проприетарщина, которой пользуются, наверное, только в яндексе. Ну и пусть оставят его себе, вместе со всем не нужным, собирающимся им. А я продолжу использовать XGBoost.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

39. Сообщение от Аноним (36), 15-Сен-20, 09:50   +/
А чем ваш meson лучше чем bake, blueprint, luamake и xmake?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

40. Сообщение от kuzulisemail (?), 15-Сен-20, 09:55   +/
> есть только на целевой платформе.

Это Вы про OSX? Я больше не знаю никаких таких целевых платформ где невозмлжно кросс-компилить. И да, сюрприз, но даже и на OSX можно Qt собрать/установить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #47

41. Сообщение от kuzulisemail (?), 15-Сен-20, 10:00   +/
> только же не прибитые гвоздями к Qt.

Можно подумать что CMake, Meson и прочие билд системы не тянут за собой еще-чего-нибудь.. Ну вот не верю я в такие чудеса что им достаточно только компилятора C/C++ чтобы это собрать (я не в курсе, честно честно).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

42. Сообщение от kuzulisemail (?), 15-Сен-20, 10:48   +/
> Использовал qbs для сборки под stm32, но все же в qmake получается проще

QMake под stm32? Проще? o_O Ну, Вы, батенька даете прикурить. ))

А если серьезно - то я не знаю, куда уже проще чем stm32 и QBS (да и не только stm32). С какими то хоть проблемами столкнулись? Что было такого сложного? Раскройте плз. свою мысль.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #52

43. Сообщение от Аноним (43), 15-Сен-20, 11:51   +/
а с фига ли ты на 2018 году акцентируешь, издабол?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #49

44. Сообщение от Аноним (44), 15-Сен-20, 11:52   +/
> Он умеет кросс-компилить?

Умеет, но через такую задницу…

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

45. Сообщение от Аноним (12), 15-Сен-20, 12:45   +/
А что и какие компании делали для продвижения других популярных OSS проектов: ffmpeg, git, OpenSSL, zlib и др., например? Как то не вспомнить их рекламы на ютуб и в ФБ. Может это не так работает и Пользователи сами сравнивают, чем кандидат лучше конкурентов?
Единственное продвиджение, которое оставалось сделать QtCompany - использовать Qbs как систему сборки Qt. Известности это бы добавило, но подвинуть тот же CMake вряд ли бы получилось.
В любом случае у Qbs был старт получше многих других OSS проектов. И раз он всеравно не взлетает, значит есть, чем не устраивает Пользователей настолько, что продолжают сидеть на CMake. И кроме зависимости от Qt, которую вспоминают в обсуждениях новостей, другой критики не встречается.
В 2016-2018 в проекте Qbs участвовало минимум 3 разработчика от QtCompany: Jake, Joerg, Christian. Еще несколько набегами и больше рецензированием кода. Но суммарно по выделенному времени там было меньше одного человека фултайм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #46

46. Сообщение от ABBAPOH (ok), 15-Сен-20, 13:01   +/
Ну представьте Линус такой написал гит а потом - блин, чот его в репозиториях нету 2 года, всё, остаюсь на svn.
Именно то что QtCompany тянуло кота за резину все эти годы и мямлило - ну мы вроде перейдем а может и не перейдем (по факту работа над портом не велась после альфы версии).
Это ОЧЕНЬ важно - продвигать свои продукты, но QtCompany констистентно фейлит в этом.
То, что юзеры сидят больше на qmake а не на qbs говорит о многом.
Вот пришел бы я к начальнику в 2018м и как бы я ему переход с qmake на Qbs продавал? "Ну они вроде хотят переходить на qbs. Но это не точно может и не хотят, я поручиться не могу".
qmake - абсолютно нерабочее говно на котором нельзя нормально сделать банальных вещей типа генерации файлов, но даже у него пользователей больше чем у Qbs при том что нет ни одного технического аргумента чем qmake лучше. Так что может проблемы лежат не в технической плоскости?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

47. Сообщение от ABBAPOH (ok), 15-Сен-20, 13:21   +/
Нет, на OSX как раз таки кросс-компиляция - ты кросс-компилируешь на amd64 маке для arm64 iOS, например.
Но ты не можешь собирать ничего на самой iOS (потому что компилятора нет).
Но вот прикол - ты можешь собрать Qbs под iOS, только зачем, без компилятора-то?
Собственно я и пытаюсь добиться хоть одного примера платформы где есть компилятор, но не портирована Qt. Охотно верю что в каком-нибудь ООО "рога и копыта" такие могут быть, но это слабый аргумент, смотреть-то надо на мажоритарных игроков (венда, линукс, мак)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #51

48. Сообщение от Аноним (48), 15-Сен-20, 13:24   –1 +/
Хуже CMake сложно что-то придумать, даже если специально очень сильно стараться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #50

49. Сообщение от Авваронemail (??), 15-Сен-20, 14:33   +/
Потому что это последний год, за который есть данные? не нравится 2018, давай возьмем 2017, убыток 3.3 ляма.
Ты на урок-то не опоздаешь, споря в интернетах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

50. Сообщение от Аноним (50), 15-Сен-20, 14:38   +/
Autotools
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

51. Сообщение от kuzulisemail (?), 15-Сен-20, 21:26   +/
Не, я имел ввиду, что из Linux/Windows невозможно кросс-компилировать для OSX.. Или возможно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #55

52. Сообщение от Аноним (52), 16-Сен-20, 22:21   +/
> С какими то хоть проблемами столкнулись? Что было такого сложного?

Принципиальных проблем c qbs нет, но документация у него хреновая... некоторые параметры вообще непонятно куда писать.

> куда уже проще чем stm32 и QBS

Самый тупой вариант для старта на qmake за 10 минут - переопределить несколько переменных (обычно от четырёх до шести). Здесь самое сложное - додуматься до QMAKE_CFLAGS -= -fPIC. Еще из неочевидного - линкерскрипт в зависимости добавить (чтобы перелинковываться при изменении линкерскрипта).

Если сравнивать qmake+makespec и поддержку платформы по феншую - примерно аналогично qbs, главное выбрать аккуратно базовую платформу.


Когда захочешь сделать что-то типа
CONFIG+=ram # слинковаться в RAM
CONFIG+=i2c # которая добавит в проект файлы/либы i2c и включит в зависимостях CONFIG+=gpio

qmake оказывается удобнее в использовании. Он заранее на подобные костыли ориентирован.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #53, #54

53. Сообщение от kuzulisemail (?), 17-Сен-20, 08:06   +/
> некоторые параметры вообще непонятно куда писать.

Позвольте, но есть же примеры, которые идут вместе с QBS. Кроме того, что может быть непонятного, там же всего пару мест куда пишутся основные параметры: это во флаги компилятора и линкера и все.

> qmake оказывается удобнее в использовании. Он заранее на подобные костыли ориентирован.

А как же QBS Properties и Profile айтемы, как же кондишины и обычные проперти? Неужели это сложнее чем в qmake?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

54. Сообщение от kuzulisemail (?), 17-Сен-20, 08:10   +/
> CONFIG+=ram # слинковаться в RAM

CONFIG+=i2c # которая добавит в проект файлы/либы i2c и включит в зависимостях CONFIG+=gpio

Неужели это проще чем сделать:

bool useI2C: true
bool linkWithRAM: true

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

55. Сообщение от Авваронemail (??), 17-Сен-20, 12:40   +/
Есть такая приблуда для линуксов https://github.com/tpoechtrager/osxcross
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру