Comments 54
Забавно) Я тоже когда-то пробовал создавать инсталляторы с помощью qbs; тогда еще 1.3 версия у меня была. Даже относительно неплохо выглядело. Но в итоге сейчас я qbs не использую, увы, он меня не устраивает.
А чем не устраивает? и чем пользуетесь? Сам пользуюсь cmake-ом, интересно, стоит ли вообще qbs изучать
Объективно могу сравнить только с qmake: производительность сборки увеличилась значительно. Например полная пересборка проекта qmake занимала около 40-50 минут, qbs же пересобирает в среднем за 15, т.к. грузит все ядра процессора. В дальнейшем он собирает только новые и изменившиеся файлы, что делает быстро. Явным плюсом к этому еще то, что он очень хорошо отслеживает зависимости и например при изменении чего-либо в статической библиотеки, собрать заново и использующие ее другие продукты, чего qmake не делает и об этом надо всегда помнить.
Qbs конечно хорош, но все конечно дело привычки. Читать его удобно и понятно, а вот писать задуманное — не сразу удается, т.к. мало информации. В любом случае думаю попробовать на каком-нибудь небольшом проекте его стоит.
Qbs конечно хорош, но все конечно дело привычки. Читать его удобно и понятно, а вот писать задуманное — не сразу удается, т.к. мало информации. В любом случае думаю попробовать на каком-нибудь небольшом проекте его стоит.
qmake сильно и не нужно грузить процессор. Он же только создает Makefile с которым дальше работает make и там уже можно разными опциями задавать кол-во процессов.
Да, вы правы — не правильно выразился. Qmake только генерирует Makefile, при этом ему можно указать в качестве параметра -j<кол-во потоков для дальнейшей сборки>. Но проблема заключается в том, что это действует только на основной Makefile, в реальности же для каждого профиля сборки далее создается свой Makefile, который и будет в дальнейшем обрабатываться make (Makefile.Debug или Makefile.Release), а на него этот аргумент уже не будет распространяться и все будет выполняться в одном потоке. Немного исправляет ситуацию утилита jom, но все равно медленнее чем qbs выходит
jom оставил у меня двоякое впечатление. С одной стороны, он гораздо лучше make грузит несколько потоков, с другой стороны при распределенной сборке — когда у вас 100 потоков компиляции допустим, сильно проигрывает ninja + часто зависает без видимой причины. (часто это в 1 из 30 запусков допустим — для CI что-то дофига).
По моим личным замерам, ninja работает с графом сборки куда эффективнее нежели qbs. это даже Jake Petroules не отрицал в комментах к релизу; только он почему-то упорно сравнивал инкрементный билд qbs с cmake+ninja, а не просто ninja, хотя я в упор не могу понять нафига при инкрементной сборке переконфигурирование.
qmake занимала около 40-50 минут, qbs же пересобирает в среднем за 15, т.к. грузит все ядра процессора
А как так получается? У меня «qmake» (на самом деле просто «make») тоже исспользует все ядра:
cd build
qmake ..
make -j12
Дело было года 2-3 назад и сборка производилась из-под QtCreator (версию уже не помню — 2.хх скорее всего). Вероятно он передавал некорректно этот атрибут для make. Сейчас поднял проект со сборкой на qmake и запустил пересборку его из-под QtCreator 4.3.0 — mingw32-make действительно распараллелил компиляцию и загрузил все ядра. Для интереса провел тест и получил интересные результаты: mingw32-make собрал за 10:19, jom за 09:27 и qbs за 11:28. Правда сопоставить сборку qbs с другими способами не совсем корректно будет, т.к. проект переехал на qbs и в нем есть изменения которых нет в qmake. Но разницу между чистым qmake и jom все таки можно увидеть.
cmake и еще раз cmake) если cmake вас не устраевает скорее всего, вы не научились его вкусно готовить) у меня в черновиках лежит статья о том, как из cmake сделать конфетку, все не доберусь до нее — там и про декларативный стиль, и про хеш-таблицы, и про многомерные массивы — короче всякая вкуснота, которую не пишут в документации и на форумах ;) надеюсь до конца лета выложу
Какую систему сборки используете сейчас, если не секрет?
Не секрет, cmake; Используемые генераторы: MSVS, Xcode, Ninja + CodeBlock для QtC, Makefiles для CLion, Ninja на билд-серверах.
Там где Ninja- используем свою систему распределенной сборки, я ее уже чуток пиарил на хабре: https://github.com/mapron/Wuild/. Ну и для makefiles/xcode она тоже (хоть и немного менее эффективно) годится.
qbs не устраивает по двум параметрам: слабая интеграция с произвольной IDE (точнее — никакая, вмерджен только начатый мной же патч для VS — и это спустя 2 года!), отсутствие интеграции с системами распределённой сборки; отсуствие коммьюнити/внятной поддержки в mailing list. По cmake туева куча готовых решений.
Синтаксис? Да, qbs им прекрасен. Кода на нем писать придется меньше и он будет читаемее. Но увы, этого маловато(
Там где Ninja- используем свою систему распределенной сборки, я ее уже чуток пиарил на хабре: https://github.com/mapron/Wuild/. Ну и для makefiles/xcode она тоже (хоть и немного менее эффективно) годится.
qbs не устраивает по двум параметрам: слабая интеграция с произвольной IDE (точнее — никакая, вмерджен только начатый мной же патч для VS — и это спустя 2 года!), отсутствие интеграции с системами распределённой сборки; отсуствие коммьюнити/внятной поддержки в mailing list. По cmake туева куча готовых решений.
Синтаксис? Да, qbs им прекрасен. Кода на нем писать придется меньше и он будет читаемее. Но увы, этого маловато(
Может не в тему, но все-таки спрошу — если qbs так хорош и создан чтобы заменить qmake, почему же он до сих пор так и не стал основной системой сборки для qt? Ведь с его представления прошло уже больше 5 лет, у него есть какие-то скрытые проблемы?
Начиная с Qt Creator 2.7 он входит в комплект поставки (например https://habrahabr.ru/post/171405/ и https://habrahabr.ru/post/181688/). Правда его интеграция в IDE до сих пор пока не полная (имею ввиду подсказки, дополнения и т.п.). Насколько знаю (пруфов не могу найти), сам Qt Creator с его инфраструктурой собирается с помощью qbs и поставляется в их же инсталляторе qt Install Framework. Если вы под
Qbs — определенно лучше qmake, но он не герболайф — у него тоже есть некоторые недостатки и иногда возникают неясные моменты в его работе. Например, иногда он не может на ровном месте создать каталог сборки продукта собираемого по моим правилам — или конечно я чего-то не указываю. Все сводится к тому,
что много чего не документировано, а если и документировано, то местами лучше бы этого не делали ))
не стал основной системой сборки для qtимеете ввиду что он не предлагается в creator как система сборки проектов по умолчанию и доступна только при включении плагина, то этот вопрос думаю следует адресовать разработчикам этого продукта.
Qbs — определенно лучше qmake, но он не герболайф — у него тоже есть некоторые недостатки и иногда возникают неясные моменты в его работе. Например, иногда он не может на ровном месте создать каталог сборки продукта собираемого по моим правилам — или конечно я чего-то не указываю. Все сводится к тому,
что много чего не документировано, а если и документировано, то местами лучше бы этого не делали ))
При nokia такого не было. Понабрали хипстеров и забили на документацию
Спасибо вам и остальным ответившим. То что он не герболайф понятно, в их существование, наверное, верят только джуниоры. Просто то что его когда-то с такой помпой объявили и 5 лет он подвизается где-то в виде отдельного плагина или же системы сборки в компании с совсем сторонним cmake не может не смущать.
А неясных моментов и багов на ровном месте (типа «не тот z поставили» или «забыли что наша библиотека имеет несколько способов создания объектов») в qt что-то в последнее время стало сильно больше, видимо вы правы про нокию (а может я старею и стал занудой, потому как субъективно кажется что это не только с qt такая проблема)
А неясных моментов и багов на ровном месте (типа «не тот z поставили» или «забыли что наша библиотека имеет несколько способов создания объектов») в qt что-то в последнее время стало сильно больше, видимо вы правы про нокию (а может я старею и стал занудой, потому как субъективно кажется что это не только с qt такая проблема)
Qbs определенно лучше qmake — да, это бесспорно. Но вот если бы Qt Project на его разработку выделяло не 1.5 разработчика (или даже меньше), а чуть побольше, и за несколько лет уделило время на решение типовых пользовательских кейсов — те же генераторы под частые форматы (либо взамен их интеграцию с 2-3 популярными IDE) — это бы привлекло возможно куда больше контрибьюторов (и багов было бы меньше).
А так — я сидел плевался с 64-битным mingw с вылезающими багами в 1.6,1.7, 1.8 — конечно, прикольно что можно все в js файлах поправить, не пересобирая, но все же…
А так — я сидел плевался с 64-битным mingw с вылезающими багами в 1.6,1.7, 1.8 — конечно, прикольно что можно все в js файлах поправить, не пересобирая, но все же…
Но вот если бы Qt Project на его разработку выделяло не 1.5 разработчика (или даже меньше), а чуть побольше
Open Source же. Кто хочет, тот может присоединиться к разработке. Малое количество разработчиков говорит о малом интересе.
Малое количество разработчиков говорит о малом интересе.Я думаю, небольшой интерес вызван тем, что сами разработчики не знают, чего хотят от qbs и будут ли они его развивать в дальнейшем вообще. Это по состоянию на сентябрь 2016, соответсвенно и сообщество не спешит инвестировать в проект с неясным будущим.
Вот именно, одно дело опенсорс и побочный проект, другое дело говорить «мы на него закладываемся к следующему мажорному релизу». У меня это в голове не стыкуется никак.
QtC тоже начинался как проект энтузиастов (примерно как мега-демка того что умеет Qt), но потом в него стали реальные ресурсы вкладывать => получился через несколько лет приличный результат. И да, я выводы свои делаю не только на основе релизов, но так же на основе рассылки, обсуждений в тикетах, комментах в пуллреквестах, я так понимаю, многие QtC разработчики скептично к нему относятся (мол, надо реальные штуки для пользователей пилить, а вы какие-то оптимизации билдграфа делаете и мутите dynamic-variadic-Rules которые хз кому нужны) — сильно перевираю цитату, Oswald в комментах какомуто задеклайненному реквесту писал, в начале 2016 года (тогда еще не влили msvs генератор)
QtC тоже начинался как проект энтузиастов (примерно как мега-демка того что умеет Qt), но потом в него стали реальные ресурсы вкладывать => получился через несколько лет приличный результат. И да, я выводы свои делаю не только на основе релизов, но так же на основе рассылки, обсуждений в тикетах, комментах в пуллреквестах, я так понимаю, многие QtC разработчики скептично к нему относятся (мол, надо реальные штуки для пользователей пилить, а вы какие-то оптимизации билдграфа делаете и мутите dynamic-variadic-Rules которые хз кому нужны) — сильно перевираю цитату, Oswald в комментах какомуто задеклайненному реквесту писал, в начале 2016 года (тогда еще не влили msvs генератор)
С релизом QBS 1.8 разработчики объявили, что станет основным в Qt 6.
Моё мнение как человека, несколько лет работающего с qbs: в большинстве случаев он очень хорош. Синтаксис прекрасен. Поддерживает не только c++ проекты. Существуют недостатки (о них ниже), которые может быть не очень-то и просто обойти. Не хватет документации и user experience — на почти все вопросы, которые я задавал на SO по qbs, отвечал один человек.
По умолчанию (и это не изменить) qbs собирает всё в загогулистую подпапку папки билда. Лучше всегда указывать destinationDirectory. Зато если destinationDirectory указан, временные файлы этапа компиляции не перемешиваются с таргетами.
Он пока еще не в полной мере поддерживает функционал qmake (пример: TYPELIBS).
Часть функционала не документирована или документирована недостаточно (пример: qbs.installSourceBase)
Лично у меня введение дополнительных этапов сборки зачастую вызывали затруднения (скажем, «выполнить somescript в процессе сборки, после компоновки»). Добавлять свои скрипты к install step нельзя
Списковые свойства (типа cpp.includePaths,cpp. dynamicLibraries и пр.) в разных контекстах могут не доопределяться, а переопределяться (доопределение в случае изменения Export или Depends на модуль; переопределение при «наследовании»).
qbs накладывает ограничения на иерархию файлов проекта. (пример: qbs-ники модулей обязаны лежать в qbsSearchPaths+"/modules/MyModuleName/MyModuleName.qbs"). Сабмодули не документированы.
Ругается на «некошерное» использование некоторого API (пример: File.DirectoryEntries)
При запуске из-под QtCreator не поддерживает console.log. Дебажить приходится через throw.
Это список тех подводных камней, с которыми я часто встречаюсь. В моём понимании, процесс билда завершен только когда приложение можно отдавать пользователю. qmake файлы трудно читать, но он пока еще более гибкий.
По умолчанию (и это не изменить) qbs собирает всё в загогулистую подпапку папки билда. Лучше всегда указывать destinationDirectory. Зато если destinationDirectory указан, временные файлы этапа компиляции не перемешиваются с таргетами.
Он пока еще не в полной мере поддерживает функционал qmake (пример: TYPELIBS).
Часть функционала не документирована или документирована недостаточно (пример: qbs.installSourceBase)
Лично у меня введение дополнительных этапов сборки зачастую вызывали затруднения (скажем, «выполнить somescript в процессе сборки, после компоновки»). Добавлять свои скрипты к install step нельзя
Списковые свойства (типа cpp.includePaths,cpp. dynamicLibraries и пр.) в разных контекстах могут не доопределяться, а переопределяться (доопределение в случае изменения Export или Depends на модуль; переопределение при «наследовании»).
qbs накладывает ограничения на иерархию файлов проекта. (пример: qbs-ники модулей обязаны лежать в qbsSearchPaths+"/modules/MyModuleName/MyModuleName.qbs"). Сабмодули не документированы.
Ругается на «некошерное» использование некоторого API (пример: File.DirectoryEntries)
При запуске из-под QtCreator не поддерживает console.log. Дебажить приходится через throw.
Это список тех подводных камней, с которыми я часто встречаюсь. В моём понимании, процесс билда завершен только когда приложение можно отдавать пользователю. qmake файлы трудно читать, но он пока еще более гибкий.
install step-ы имхо очень неочевидные у них. Я так и не понял как вообще там можно сделать в рамках одного проекта фиксап саббандлов для макоси… чтобы с подписью и все такое)
«Дебажить приходится через throw.» — не следил за последними релизами, ДО СИХ ПОР?? это же ахтунг)
Отлично вываливает отладочные логи при вызове
console.error("message")Да, вы правы, моя информация устарела. Хотя, возможно, как раз за последние три месяца. Перепроверил (командная строка | вывод QtCreator -> вкладка, отображается как):
Еще вывод throw почему-то содержит что-то вида " at () in… at () in ...".
Итого: console.log|console.debug не выводится, остальным в принципе можно пользоваться. Спасибо за наводку
property bool test: {
console.log("log")
console.info("info") // "info" | "info" -> General messages
console.debug("debug")
console.warn("warning") // "WARNING: warning" | "warning" -> Issues, warning
console.error("error") // "ERROR: error" | "error" -> Issues, warning
throw "exception" // "ERROR: exception" | "exception" -> Issues, error
}
Еще вывод throw почему-то содержит что-то вида " at () in… at () in ...".
Итого: console.log|console.debug не выводится, остальным в принципе можно пользоваться. Спасибо за наводку
Зачем инвестировать в изучение qbs если есть cmake, который может всё тоже и намного больше, и уже является стандартом де-факто, а qbs на это даже не претендует?
Я всё таки не понимаю, почему в Qt решили создавать qbs, а не перейти на cmake? Я просматривал пост разработчиков, где они обсуждают cmake, но кроме «нет того, чего нам хотелось бы» никаких причин не увидел. Так и хочется ответить: «Ну так пользуйтесь тем, что есть»! Мне как разработчику очень не хочется изучать ещё одну систему сборки, которую я смогу использовать только для qt-проектов и то не понятно когда, т.к. qbs до сих пор не стал основной системой сборки даже для Qt. Я бы понял, если бы они решили сделать киллера cmake, не завязанного на Qt, а претендующего на замену cmake во всех его основных нишах, но для этого нужно выделить кучу ресурсов, чего не видно.
Я всё таки не понимаю, почему в Qt решили создавать qbs, а не перейти на cmake? Я просматривал пост разработчиков, где они обсуждают cmake, но кроме «нет того, чего нам хотелось бы» никаких причин не увидел. Так и хочется ответить: «Ну так пользуйтесь тем, что есть»! Мне как разработчику очень не хочется изучать ещё одну систему сборки, которую я смогу использовать только для qt-проектов и то не понятно когда, т.к. qbs до сих пор не стал основной системой сборки даже для Qt. Я бы понял, если бы они решили сделать киллера cmake, не завязанного на Qt, а претендующего на замену cmake во всех его основных нишах, но для этого нужно выделить кучу ресурсов, чего не видно.
Видимо, разработчики Qt и сами осознают проблему и по состоянию на сентябрь 2016 сами не решили, перейти ли на cmake или продолжать развивать qbs и, если да, то в каком виде: qt-specific tool или универсальной build-tool.
We are thinking about switching build systems. We don't know what to do yet…
Мне как разработчику очень не хочется изучать ещё одну систему сборки, которую я смогу использовать только для qt-проектов
так он же не только для qt-проектов
теоретически. На практике никаких подвижек в сторону того что бы сделать qbs действительно универсальным build tool не видно.
К примеру, я не смог найти механизма поиска внешних зависимостей аналогичного find_package() в cmake. Как собирать приложение с boost и python bindings, к примеру, в ручную для каждой платформы всё прописывать? И это я ещё не отошел от c++.
К примеру, я не смог найти механизма поиска внешних зависимостей аналогичного find_package() в cmake. Как собирать приложение с boost и python bindings, к примеру, в ручную для каждой платформы всё прописывать? И это я ещё не отошел от c++.
Я всё таки не понимаю, почему в Qt решили создавать qbs, а не перейти на cmake?
Как бы CMake Manual в официальной документации, да и cmake модули поставляются с Qt.
Они поддерживают cmake, но не так хорошо как qmake, и решения об использовании cmake как основного build tool в будущем принято не было, хотя, видимо, такая возможность до сих пор рассматривается.
Они это кто? Digia, KDE Free Qt Foundation или кто-то еще?
разработчики qbs и Qt в целом, судя по QtCon 2016.
В частности, QtCreator работает с cmake не так хорошо, как c qmake.
Мне кажется, сделать убийцу cmake было бы здорово, но для этого нужно много ресурсов и, как минимум, нужно поставить такую цель. А делать buid-system с мыслью что она будет использоваться только в контексте Qt — странная затея, на мой взгляд.
(Tobias) Cmake is the «worst» system in Qt Creator because CMake doesn't give enough feedback to the IDE. We need first-class support for CMake in Qt Creator...
Мне кажется, сделать убийцу cmake было бы здорово, но для этого нужно много ресурсов и, как минимум, нужно поставить такую цель. А делать buid-system с мыслью что она будет использоваться только в контексте Qt — странная затея, на мой взгляд.
Как бы не стоит мешать Qt и QtCreator.
Мне кажется, сделать убийцу cmake было бы здорово, но для этого нужно много ресурсов и, как минимум, нужно поставить такую цель
А кому это нужно? Я у вас пытаюсь узнать, какая из компаний пилит этот Qbs. В итоге непонятно, кому этот проект нужен и для чего.
К сожалению, огромному, из коммерческих компаний — не нужно никому. Как я понял, по косвенным комментам, даже разработчикам Qt Project на qbs время не выделяют особо. Может я и ошибаюсь, но не вижу ничего сильно доказывающего обратное.
Разработчикам это было бы полезно как инфраструктурная вещь — cmake не слишком удобен и вполне понятно, что можно было бы сделать лучше. Кто из организаций хочет этим заняться я не знаю. Выглядит так, будто никто вообще не знает, в какую сторону будет развиваться qbs и не умрёт ли через год.
Как я понял, изначально qbs родился как замена qmake, который стало слишком сложно поддерживать, о чем Trolltech писали ещё в 2009 (или раньше). Qmake, на сколько я могу судить, никогда не претендовал на то, что бы стать универсальной билд-системой типа cmake, а чисто занимал нишу билд-тула для Qt-проектов. Соответсвенно, поскольку qbs начался как наследник qmake — можно подумать, что его нацеливали в ту же нишу. Однако в этой нише он, имхо, не нужен т.к. сегодня у нас есть cmake. Но и чёткой цели создать конкурента cmake перед qbs тоже, похоже, не поставили.
Как я понял, изначально qbs родился как замена qmake, который стало слишком сложно поддерживать, о чем Trolltech писали ещё в 2009 (или раньше). Qmake, на сколько я могу судить, никогда не претендовал на то, что бы стать универсальной билд-системой типа cmake, а чисто занимал нишу билд-тула для Qt-проектов. Соответсвенно, поскольку qbs начался как наследник qmake — можно подумать, что его нацеливали в ту же нишу. Однако в этой нише он, имхо, не нужен т.к. сегодня у нас есть cmake. Но и чёткой цели создать конкурента cmake перед qbs тоже, похоже, не поставили.
cmake не слишком удобен
И что же это KDE Free Qt Foundation, которая отвечает за развитие open source версии Qt, не взялось за это, а использует "неудобный" CMake?
Потому что не считают, что создание более удобного build-tool — это для них приоритетная задача, или, может быть считают, что такая задача им не по силам? Это ведь огромная работа — нужно не только синтаксис удобный продумать, но и как-то обеспечить поддержку нескольких в IDE, научить систему поддержке разных зависимостей хотя бы на основных 3х-5ти платформах и т.д.
А чисто красивого синтаксиса и скорости не достаточно, есть ведь tup, но что-то я не вижу что бы он заменил cmake.
А чисто красивого синтаксиса и скорости не достаточно, есть ведь tup, но что-то я не вижу что бы он заменил cmake.
Потому что не считают, что создание более удобного build-tool
Это все очень субъективно.
но и как-то обеспечить поддержку нескольких в IDE
Это проблема конкретных IDE поддержать инструменты иначе это уже не Integrated Development Environment
Это проблема конкретных IDE поддержать инструменты иначе это уже не Integrated Development EnvironmentНу почему же, Integrated не означает Ultimately Universal. Integrated значит что то, что поддерживается — хорошо интегрировано с другими поддерживаемыми инструментами. В каких IDE есть нормальная поддержка qbs? Кроме того, я не уверен, что разработчик предпочтёт отказаться от любимой IDE в пользу любимого build-tool. Что бы IDE стали поддерживать build-tool, tool должен быть достаточно важным, а что бы этого добиться нужно приложить немало усилий, и создание плагинов для популярных IDE скорее всего положительно отразится на развитии самого тула, и увеличит вероятность того, что и другие IDE тоже станут его поддерживать. Поэтому мне кажется, что разработчики нового билд-тула более заинтересованы в разработке плагинов под популярные IDE, чем разработчики этих IDE.
Я с вами полностью согласен. С тем же cmake — это его разработчики создают и оттачивают генераторы, а не разработчики MSVS, Xcode, kate или CodeBlocks =)
Что-то разработчики make не оттачивают плагины к MSVS, Xcode, CodeBlocks, CLion, Eclipse.
make такая же система сборки, как и msbuild или xcodebuild. только плюс к тому еще и древняя, когда она начинала получать распространение — об интеграции IDE думать не приходилось.
разработчик ninja тоже как-то не задумывается о плагинах =)
если хотите проводить такую же аналогию то лучше подойдут autotools. Ну и да, там разработчики сильно не заморачивались, и посмотрите сколько использует autotools и сколько — cmake. Я для сборки ffmpeg написал cmake-скрипты только чтобы была возможность отладки в IDE удобным путем =)
Вообще, на самом деле еще все очень сильно зависит от устоявшейся ситуации на рынке. Допустим, если я сейчас напишу свою IDE для C++, то будет очень странно, если там не будет интеграции с cmake и возможности сборки через make или ninja (лучше если оба). Если этого нет — то сразу количество моих пользователей резко падает. Соответственно, разработчики cmake уже будут незаинтересованы.
У IDE XCode и VS — большая аудитория. Много разработчиков их использует и к ним привыкли. Если я делаю свою супер-пупер крутую систему сборки, которая рвет конкурентов и все такое — но забываю про удобную интеграцию с популярными IDE — я теряю своих пользователей. У меня нет пользователей — разработчики IDE не хотят заморачиваться с поддержкой меня) замкнутый круг.
Посмотрите на решения от Xoreax — они предлагают интеграцию с целым рядом сборочных систем (про качество и цену я сейчас умолчу — но сам подход я считаю верным).
В итоге — либо ты обладаешь большой аудиторией и можешь другим навязывать свою стратегию, либо подстраиваешься под других, если хочешь выползти наверх. Хорошо, плохо, аморально ли это — это за пределами моего утверждения.
Да, в «топе» могут держаться далеко не идеальные системы сборки и IDE =) но зато это дает больше шансов «ворваться» кому-то еще.
разработчик ninja тоже как-то не задумывается о плагинах =)
если хотите проводить такую же аналогию то лучше подойдут autotools. Ну и да, там разработчики сильно не заморачивались, и посмотрите сколько использует autotools и сколько — cmake. Я для сборки ffmpeg написал cmake-скрипты только чтобы была возможность отладки в IDE удобным путем =)
Вообще, на самом деле еще все очень сильно зависит от устоявшейся ситуации на рынке. Допустим, если я сейчас напишу свою IDE для C++, то будет очень странно, если там не будет интеграции с cmake и возможности сборки через make или ninja (лучше если оба). Если этого нет — то сразу количество моих пользователей резко падает. Соответственно, разработчики cmake уже будут незаинтересованы.
У IDE XCode и VS — большая аудитория. Много разработчиков их использует и к ним привыкли. Если я делаю свою супер-пупер крутую систему сборки, которая рвет конкурентов и все такое — но забываю про удобную интеграцию с популярными IDE — я теряю своих пользователей. У меня нет пользователей — разработчики IDE не хотят заморачиваться с поддержкой меня) замкнутый круг.
Посмотрите на решения от Xoreax — они предлагают интеграцию с целым рядом сборочных систем (про качество и цену я сейчас умолчу — но сам подход я считаю верным).
В итоге — либо ты обладаешь большой аудиторией и можешь другим навязывать свою стратегию, либо подстраиваешься под других, если хочешь выползти наверх. Хорошо, плохо, аморально ли это — это за пределами моего утверждения.
Да, в «топе» могут держаться далеко не идеальные системы сборки и IDE =) но зато это дает больше шансов «ворваться» кому-то еще.
об интеграции IDE думать не приходилось.
Всем фиолетово.
Допустим, если я сейчас напишу свою IDE для C++
А может лучше вы поможете в разработке qbs, вместо того, что бы жаловаться про 1.5 разработчика.
Соответственно, разработчики cmake уже будут незаинтересованы.
Откуда интерес, если они не имеют с этого денег?
либо подстраиваешься под других, если хочешь выползти наверх.
Какой верх у open source решений? Сторонние разработчики добавляют в cmake то, что им нужно, а не ждут пока kitware добавит генератор под IDE.
А может лучше вы поможете в разработке qbs, вместо того, что бы жаловаться про 1.5 разработчика.
https://bugreports.qt.io/browse/QBS-31
Кхм. Я сделал пуллреквест. Исправил замечания. Можете посмотреть. Потом спросил «чуваки, что еще надо, чтобы он попал в апстрим?» почитайте комменты на геррите.
В итоге спустя 2 года msvs генератор после еще одного рефакторинга (Jake его попилил на большее количество файлов, респект и уважуха, но не принципиально) он таки попал в апстрим.
Может быть для вас это нормальный темп разработки. Но для меня он не сравним с темпом разработки самого Qt, извините. Лично для меня пыл контрибьютить в qbs угас.
https://bugreports.qt.io/browse/QBS-31
Кхм. Я сделал пуллреквест. Исправил замечания. Можете посмотреть. Потом спросил «чуваки, что еще надо, чтобы он попал в апстрим?» почитайте комменты на геррите.
В итоге спустя 2 года msvs генератор после еще одного рефакторинга (Jake его попилил на большее количество файлов, респект и уважуха, но не принципиально) он таки попал в апстрим.
Может быть для вас это нормальный темп разработки. Но для меня он не сравним с темпом разработки самого Qt, извините. Лично для меня пыл контрибьютить в qbs угас.
Я активно агитировал за переход на qbs, весь деплой и сборка инсталляторов одной коммерческой компании перевел на него; более того, он даже сейчас, спустя 2 года после моего ухода, остается там :) моя претензия в этой ветке выражалась в одной фразе — если Qt Project утверждает в официальном блоге что они хотят сделать qbs основной системой сборки — это ПОКА не согласуется с теми ресурсами, которые на неё выделяют. Она замечательная, няшная, и я всецело буду рад, если они действительно сделают её таковой)
А вы начинаете переходить на личности «чего жалуетесь что там мало народу, сами помогайте» — ну простите, как то странно, что сами разработчики должны брать меня в расчет, когда планируют разработку :D
А вы начинаете переходить на личности «чего жалуетесь что там мало народу, сами помогайте» — ну простите, как то странно, что сами разработчики должны брать меня в расчет, когда планируют разработку :D
Sign up to leave a comment.
Катаем «смоляной шарик» или создание собственных правил сборки с помощью Qbs