1.4, yurkis (ok), 18:00, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Мне не очевидно чем (кроме модного ныне JS) эта штука лучше CMake/SCons
| |
|
|
3.13, yurkis (ok), 20:14, 16/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Отработка дерева зависимостей быстрее на 4с? Проект должен быть ну ОООЧЕНЬ большим чтобы почуствовать разницу. Для инкрементально сборки "в стиле Eclipse" только... Но кто этим пользуется? Многопоточность (кто сказал make -j3)?
Может тогда расширяемость за счет скриптов? Так тут до SCons еще пилить и пилить.
Я конечно люблу Qt, но тут мне не очевидно.
| |
|
4.23, Sauron (??), 23:19, 16/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
qml вообще-то by design жутко удобен для подобных задач. Опять же это только кажется, что на нем только гуй удобно делать, он вполне пригоден и для выполнения других задач.
| |
|
5.28, arisu (ok), 11:20, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Опять же это только кажется, что на нем только гуй удобно делать
…а на самом деле неудобно даже это.
| |
|
|
|
|
1.7, lucentcode (ok), 19:01, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Хорошее начинание. Когда разовьют немного, будет очень удобно пользоваться. А пока Make - наше всё, ну и Ant иногда.
| |
1.9, Аноним (-), 19:08, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не внимательно читаем? Скорость сборки выше, гибкость для каких-то магических действий сборки
| |
1.22, Sauron (??), 23:18, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Такс, а что мешало qmake и раньше использовать для сборки обычных C++/C приложений? Я так частенько делал и все прекрасно работало и собиралось :)
Просто нигде не афишируется, что qmake можно и не для Qtшных прог использовать, да и собрать qmake отдельно от Qt тот ещё процесс, хотя он тоже в принципе способен без установленных Qt работать, нужны только mkspecs'ы.
Впрочем у qbs синтаксис всё равно круче и было бы клево его видеть в виде отдельного проекта.
| |
|
2.24, добрый дядя (?), 23:44, 16/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Такс, а что мешало qmake и раньше использовать для сборки обычных C++/C приложений?
ничего не мешало, я давно уже qmake юзаю для любых C++ прог как нормальную беспроблемную систему сборки на разных ОСях
а qbs судя по всему позволит еще и Java и прочие проекты собирать чтоб может стать весьма приятным и универсальным средством... cmake не предлагать, юзайте его сами если считаете нужным, а простые мелкие прожки в конторках - qbs
| |
|
3.30, green (??), 12:22, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
qmake - очень слабенькая система сборки посравнению с аналогами. Если проект подвязан только к Qt + ещё простые библиотеки то недостатки неощутимы, кроме одного - это out-of-source-tree builds.
Но вот когда юзать qmake с другими фреймворками - boost, ACE и тд - то начинаюися проблемы.
Вобщем в этом случаие CMake выше на голову - но недостаток в том что он сложнее + дополнительная зависимость
| |
|
4.32, annulen (?), 13:26, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>кроме одного - это out-of-source-tree builds
qmake давно это умеет, только реализовано немного кривовато (каталог сборки не может находиться внутри каталоги с исходниками)
| |
|
5.33, green (??), 13:35, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Да знаю о таком функционале. Но снова таки слабенько. Сборка происходет в папке с исходными файлами и надо задавать флаги qmake или явно прописывать в pro файле - это менее удобто чем то как это реализовано в CMake
| |
|
4.36, arisu (ok), 14:32, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> out-of-source-tree builds.
кстати, а зачем? вот у меня jam, например, складывает объектники в спецкаталог, равно как и бинари, и библиотеки; в рабочих каталогах с исходниками не гадит вообще, если сильно не попросить. вот я ним уж сколько лет пользуюсь и не могу понять восторгов по поводу oostb. только и радости, что скрипты усложняют.
| |
|
|
|
1.27, arisu (ok), 11:18, 17/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
из долгих обсуждений в их бложеге я в своё время так и не понял, чем им не понравился jam (в любой из его инкарнаций). ну, кроме обычного Фатального Недостатка.
зато не требует никаких кусков Qt, собирается любым си-компилятором, имеет вполне себе turing-complete язык, умеет рассматривать проект в куче каталогов как одно целое, умеет сканировать исходники на предмет include и кэшировать это… вдобавок лицензия почти что public domain, с включением в любой проект проблем нет.
в общем, моя не понимать. моя использовать модифицированый jam для проектов как в пару строк, так и для больших комплексов с кучей независимых библиотек, опций сборки и так далее. параллелится, работает реактивно, генерит документацию и разные данные. дёшево, удобно, сердито.
p.s. прошу не путать с boost.jam: это мутант, больной овердизайном, как и сам буст.
| |
|
2.55, Аноним (-), 01:14, 22/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
представь что у нас есть человек который освоил js и qml и написал программу, а тут бац за пять минут он понял как её собрать с помощью qbs.. и когда ему понадобится добавлять сложную логику он просто напишет её на явоскрипте а не на языке системы сборки.
| |
|
|
2.37, arisu (ok), 14:39, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Используйте Premake
а ты бы почитал причины, по которым «генераторы makefile-сов» были забракованы, что ли. сам по себе premake хорош, но вот формой не подходит.
| |
|
3.38, annulen (?), 16:24, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Если ты про пункт "Build directly from tool", то он полон взаимоисключающих параграфов. Во-первых, идет речь про вызовы CMake изнутри мейкфалов, чем Premake не грешит, да и вообще генерация мейкфайлов сама по себе не предполагает этой антифичи. (Для каких-то кастомных шагов это может быть допустимо, но CMake делает из этого систему) Во-вторых, далее следует фраза "Waf is better in this respect, but both lack a proper set of backends for project generations (Vcproj, XCode, Makefiles etc).".
Вобщем, на мой взгляд, реальные причины - "не JavaScript" и "не наши имена в копирайтах".
| |
|
4.39, arisu (ok), 17:40, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Если ты про пункт "Build directly from tool"
нет, я про то, что make не видит проект, раскиданый по каталогам, как одно целое. уж кто только не ругался на рекурсивные вызовы make в подкаталогах. это пытаются полечить костылями разной степени уродливости, но нафэйхоа? намного проще не использовать make.
| |
|
5.40, annulen (ok), 17:51, 17/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Совершенно бессмысленный аргумент. В той статье написано, что рекурсивный мейк не нужен. Так генерите нерекурсивные мейкфалы, и будет вам Щастье. Нет, блин, все пытаются свой мейк для этого написать.
Из всех проектов по замене мейка внимания заслуживает только ninja.
| |
|
6.41, arisu (ok), 17:55, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Совершенно бессмысленный аргумент.
это туда, в нокию.
> В той статье написано, что рекурсивный мейк не нужен.
им осталось сделать ещё жажок и убрать слово «рекурсивный».
> Нет, блин, все пытаются свой мейк для этого написать.
далеко не только для этого, сия фича — просто вкусный бонус.
> Из всех проектов по замене мейка внимания заслуживает только ninja.
у make обнаружился Фатальный Недостаток, ага. это я намекаю, что «замена make» не нужна, равно как и сам make. а нинзя — это не пришей системе шлейф какой-то.
| |
|
7.42, annulen (ok), 18:11, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Интересная логическая цепочка: "рекурсиный мейк не нужен" - "так не используй его через ж^W^W рекурсивно" - "да наплевать, все равно мейк не нужен".
| |
7.43, annulen (ok), 18:18, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
У ninja цель совершенно четкая - отделить построение DAG целей сборки и их выполнение от любых "конфигурационных" действий, чем страдает мейк. Конфигуратор делает свою работу, а нинзя - свою.
| |
|
8.45, arisu (ok), 19:12, 17/02/2012 [^] [^^] [^^^] [ответить] | +/– | это мы уже проходили, autocrap называется для больших проектов конфигуратор мож... текст свёрнут, показать | |
|
|
|
5.47, Michael Shigorin (ok), 19:31, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> нет, я про то, что make не видит проект, раскиданый по каталогам,
> как одно целое. уж кто только не ругался на рекурсивные вызовы
> make в подкаталогах.
Виденная критика была местами крива сама по себе. Впрочем, обстоятельно сейчас не расскажу.
| |
|
6.48, arisu (ok), 19:43, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Виденная критика была местами крива сама по себе. Впрочем, обстоятельно сейчас
> не расскажу.
ну, кое-как, с матами и воплями оно костылится.
так же, как костылится просчёт зависимостей (уж простейшие-то include система может и сама просканировать, я что, дятел — долбить ей это или костыли дёргать?).
а уж про «проект — это все *.c в каталоге исходников» (опять же, с просчётом зависимостей и ты пы)… не, не будем о грустном.
тот же Jam делает подобное несколькими строками. и вообще мал, реактивен (в плане скорости), удобен. для проектов среднего уровня можно его использовать и как конфигуратор заодно. да-да, я фанат jam'а, если кто ещё не заметил. и ниасилятор всего остального.
| |
|
7.50, annulen (ok), 20:08, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Просчет зависимостей делает компилятор и генерерует .d файлы, достаточно его об это попросить. Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо рекурсивных вызовов.
| |
|
8.52, arisu (ok), 20:20, 17/02/2012 [^] [^^] [^^^] [ответить] | +/– | это неудобно, хотя и точнее, чем можно сделать в билд-системе и медленней, кста... текст свёрнут, показать | |
|
|
|
|
|
|
|
|