А может лучше вы поможете в разработке qbs, вместо того, что бы жаловаться про 1.5 разработчика.
https://bugreports.qt.io/browse/QBS-31
Кхм. Я сделал пуллреквест. Исправил замечания. Можете посмотреть. Потом спросил «чуваки, что еще надо, чтобы он попал в апстрим?» почитайте комменты на геррите.
В итоге спустя 2 года msvs генератор после еще одного рефакторинга (Jake его попилил на большее количество файлов, респект и уважуха, но не принципиально) он таки попал в апстрим.
Может быть для вас это нормальный темп разработки. Но для меня он не сравним с темпом разработки самого Qt, извините. Лично для меня пыл контрибьютить в qbs угас.
make такая же система сборки, как и msbuild или xcodebuild. только плюс к тому еще и древняя, когда она начинала получать распространение — об интеграции IDE думать не приходилось.
разработчик ninja тоже как-то не задумывается о плагинах =)
если хотите проводить такую же аналогию то лучше подойдут autotools. Ну и да, там разработчики сильно не заморачивались, и посмотрите сколько использует autotools и сколько — cmake. Я для сборки ffmpeg написал cmake-скрипты только чтобы была возможность отладки в IDE удобным путем =)
Вообще, на самом деле еще все очень сильно зависит от устоявшейся ситуации на рынке. Допустим, если я сейчас напишу свою IDE для C++, то будет очень странно, если там не будет интеграции с cmake и возможности сборки через make или ninja (лучше если оба). Если этого нет — то сразу количество моих пользователей резко падает. Соответственно, разработчики cmake уже будут незаинтересованы.
У IDE XCode и VS — большая аудитория. Много разработчиков их использует и к ним привыкли. Если я делаю свою супер-пупер крутую систему сборки, которая рвет конкурентов и все такое — но забываю про удобную интеграцию с популярными IDE — я теряю своих пользователей. У меня нет пользователей — разработчики IDE не хотят заморачиваться с поддержкой меня) замкнутый круг.
Посмотрите на решения от Xoreax — они предлагают интеграцию с целым рядом сборочных систем (про качество и цену я сейчас умолчу — но сам подход я считаю верным).
В итоге — либо ты обладаешь большой аудиторией и можешь другим навязывать свою стратегию, либо подстраиваешься под других, если хочешь выползти наверх. Хорошо, плохо, аморально ли это — это за пределами моего утверждения.
Да, в «топе» могут держаться далеко не идеальные системы сборки и IDE =) но зато это дает больше шансов «ворваться» кому-то еще.
Я с вами полностью согласен. С тем же cmake — это его разработчики создают и оттачивают генераторы, а не разработчики MSVS, Xcode, kate или CodeBlocks =)
Ну, использовать одно. А именно активно контрибьютить, причем желательно чтобы разработчик этому уделял полное время на зарплате — это другое.
Так вон и 2гис qbs использует вовсю — толку-то?
К сожалению, огромному, из коммерческих компаний — не нужно никому. Как я понял, по косвенным комментам, даже разработчикам Qt Project на qbs время не выделяют особо. Может я и ошибаюсь, но не вижу ничего сильно доказывающего обратное.
Вот именно, одно дело опенсорс и побочный проект, другое дело говорить «мы на него закладываемся к следующему мажорному релизу». У меня это в голове не стыкуется никак.
QtC тоже начинался как проект энтузиастов (примерно как мега-демка того что умеет Qt), но потом в него стали реальные ресурсы вкладывать => получился через несколько лет приличный результат. И да, я выводы свои делаю не только на основе релизов, но так же на основе рассылки, обсуждений в тикетах, комментах в пуллреквестах, я так понимаю, многие QtC разработчики скептично к нему относятся (мол, надо реальные штуки для пользователей пилить, а вы какие-то оптимизации билдграфа делаете и мутите dynamic-variadic-Rules которые хз кому нужны) — сильно перевираю цитату, Oswald в комментах какомуто задеклайненному реквесту писал, в начале 2016 года (тогда еще не влили msvs генератор)
install step-ы имхо очень неочевидные у них. Я так и не понял как вообще там можно сделать в рамках одного проекта фиксап саббандлов для макоси… чтобы с подписью и все такое)
Смелое заявление. Либо Qt 6 планируют выпустить лет через 10, либо все же в qbs придет команда сильных разработчиков которые будут ему уделять время фулл-тайм. Иначе не вижу способа сдержать обещанное.
Qbs определенно лучше qmake — да, это бесспорно. Но вот если бы Qt Project на его разработку выделяло не 1.5 разработчика (или даже меньше), а чуть побольше, и за несколько лет уделило время на решение типовых пользовательских кейсов — те же генераторы под частые форматы (либо взамен их интеграцию с 2-3 популярными IDE) — это бы привлекло возможно куда больше контрибьюторов (и багов было бы меньше).
А так — я сидел плевался с 64-битным mingw с вылезающими багами в 1.6,1.7, 1.8 — конечно, прикольно что можно все в js файлах поправить, не пересобирая, но все же…
cmake и еще раз cmake) если cmake вас не устраевает скорее всего, вы не научились его вкусно готовить) у меня в черновиках лежит статья о том, как из cmake сделать конфетку, все не доберусь до нее — там и про декларативный стиль, и про хеш-таблицы, и про многомерные массивы — короче всякая вкуснота, которую не пишут в документации и на форумах ;) надеюсь до конца лета выложу
jom оставил у меня двоякое впечатление. С одной стороны, он гораздо лучше make грузит несколько потоков, с другой стороны при распределенной сборке — когда у вас 100 потоков компиляции допустим, сильно проигрывает ninja + часто зависает без видимой причины. (часто это в 1 из 30 запусков допустим — для CI что-то дофига).
По моим личным замерам, ninja работает с графом сборки куда эффективнее нежели qbs. это даже Jake Petroules не отрицал в комментах к релизу; только он почему-то упорно сравнивал инкрементный билд qbs с cmake+ninja, а не просто ninja, хотя я в упор не могу понять нафига при инкрементной сборке переконфигурирование.
Не секрет, 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 им прекрасен. Кода на нем писать придется меньше и он будет читаемее. Но увы, этого маловато(
Забавно) Я тоже когда-то пробовал создавать инсталляторы с помощью qbs; тогда еще 1.3 версия у меня была. Даже относительно неплохо выглядело. Но в итоге сейчас я qbs не использую, увы, он меня не устраивает.
Для тех, кому интересно: проект не заброшен, поддерживается, я выпустил релиз 0.2 с различными исправлениями-улучшениями. Кроме того, система успешно работает в продакшене, обслуживая 2 билда на Mac, 2 на Win + 3 слейв-машины для сборки на Win.
https://github.com/mapron/Wuild/releases/tag/v0.2
У меня вопрос к тем, кто их уже успел поковырять: как там обстоят дела с параллельной сборкой?
Допустим у меня такие файлы:
foo.cpp
bar.cpp
module.hpp
Модуль используется в обоих foo.cpp и bar.cpp. Соответственно, когда компилятор будет процессить модуль, ему нужно будет где-то сохранить результат. Я правильно понимаю, что до того как для module.hpp будет скомпилено бинарное представление (AST или что там), то нельзя начинать компилить foo или bar? ну а иначе же они могут одновременно попытаться получить/скомпилить данные module.hpp?
upd: кажется, да, понял, для компиляции по крайней мере msvc нужно указывать уже скомпиленные модули
Например, вставил несколько стандартных инклюдов типа iostream — и хоп! компилятору нужно уже мегабайтный файл процессить. А так у него уже готовые AST будут.
По сути, это эволюционное развитие идеи preprocessed headers, но на уровне одного хедера)
https://bugreports.qt.io/browse/QBS-31
Кхм. Я сделал пуллреквест. Исправил замечания. Можете посмотреть. Потом спросил «чуваки, что еще надо, чтобы он попал в апстрим?» почитайте комменты на геррите.
В итоге спустя 2 года msvs генератор после еще одного рефакторинга (Jake его попилил на большее количество файлов, респект и уважуха, но не принципиально) он таки попал в апстрим.
Может быть для вас это нормальный темп разработки. Но для меня он не сравним с темпом разработки самого Qt, извините. Лично для меня пыл контрибьютить в qbs угас.
разработчик ninja тоже как-то не задумывается о плагинах =)
если хотите проводить такую же аналогию то лучше подойдут autotools. Ну и да, там разработчики сильно не заморачивались, и посмотрите сколько использует autotools и сколько — cmake. Я для сборки ffmpeg написал cmake-скрипты только чтобы была возможность отладки в IDE удобным путем =)
Вообще, на самом деле еще все очень сильно зависит от устоявшейся ситуации на рынке. Допустим, если я сейчас напишу свою IDE для C++, то будет очень странно, если там не будет интеграции с cmake и возможности сборки через make или ninja (лучше если оба). Если этого нет — то сразу количество моих пользователей резко падает. Соответственно, разработчики cmake уже будут незаинтересованы.
У IDE XCode и VS — большая аудитория. Много разработчиков их использует и к ним привыкли. Если я делаю свою супер-пупер крутую систему сборки, которая рвет конкурентов и все такое — но забываю про удобную интеграцию с популярными IDE — я теряю своих пользователей. У меня нет пользователей — разработчики IDE не хотят заморачиваться с поддержкой меня) замкнутый круг.
Посмотрите на решения от Xoreax — они предлагают интеграцию с целым рядом сборочных систем (про качество и цену я сейчас умолчу — но сам подход я считаю верным).
В итоге — либо ты обладаешь большой аудиторией и можешь другим навязывать свою стратегию, либо подстраиваешься под других, если хочешь выползти наверх. Хорошо, плохо, аморально ли это — это за пределами моего утверждения.
Да, в «топе» могут держаться далеко не идеальные системы сборки и IDE =) но зато это дает больше шансов «ворваться» кому-то еще.
Так вон и 2гис qbs использует вовсю — толку-то?
QtC тоже начинался как проект энтузиастов (примерно как мега-демка того что умеет Qt), но потом в него стали реальные ресурсы вкладывать => получился через несколько лет приличный результат. И да, я выводы свои делаю не только на основе релизов, но так же на основе рассылки, обсуждений в тикетах, комментах в пуллреквестах, я так понимаю, многие QtC разработчики скептично к нему относятся (мол, надо реальные штуки для пользователей пилить, а вы какие-то оптимизации билдграфа делаете и мутите dynamic-variadic-Rules которые хз кому нужны) — сильно перевираю цитату, Oswald в комментах какомуто задеклайненному реквесту писал, в начале 2016 года (тогда еще не влили msvs генератор)
А так — я сидел плевался с 64-битным mingw с вылезающими багами в 1.6,1.7, 1.8 — конечно, прикольно что можно все в js файлах поправить, не пересобирая, но все же…
Там где Ninja- используем свою систему распределенной сборки, я ее уже чуток пиарил на хабре: https://github.com/mapron/Wuild/. Ну и для makefiles/xcode она тоже (хоть и немного менее эффективно) годится.
qbs не устраивает по двум параметрам: слабая интеграция с произвольной IDE (точнее — никакая, вмерджен только начатый мной же патч для VS — и это спустя 2 года!), отсутствие интеграции с системами распределённой сборки; отсуствие коммьюнити/внятной поддержки в mailing list. По cmake туева куча готовых решений.
Синтаксис? Да, qbs им прекрасен. Кода на нем писать придется меньше и он будет читаемее. Но увы, этого маловато(
https://github.com/mapron/Wuild/releases/tag/v0.2
Допустим у меня такие файлы:
foo.cpp
bar.cpp
module.hpp
Модуль используется в обоих foo.cpp и bar.cpp. Соответственно, когда компилятор будет процессить модуль, ему нужно будет где-то сохранить результат. Я правильно понимаю, что до того как для module.hpp будет скомпилено бинарное представление (AST или что там), то нельзя начинать компилить foo или bar? ну а иначе же они могут одновременно попытаться получить/скомпилить данные module.hpp?
upd: кажется, да, понял, для компиляции по крайней мере msvc нужно указывать уже скомпиленные модули
По сути, это эволюционное развитие идеи preprocessed headers, но на уровне одного хедера)