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

Разработчики Qt представили инструментарий для сборки проект..., opennews (??), 16-Фев-12, (0) [смотреть все] Мне не очевидно чем кроме модного ныне JS эта штука лучше CMake SCons, yurkis (ok), 18:00 , 16-Фев-12, (4) +3 // второй абзац новости, Аноним (-), 18:42 , 16-Фев-12, (5) +1 // Отработка дерева зависимостей быстрее на 4с Проект должен быть ну ОООЧЕНЬ больш, yurkis (ok), 20:14 , 16-Фев-12, (13) // qml вообще-то by design жутко удобен для подобных задач Опять же это только каж, Sauron (??), 23:19 , 16-Фев-12, (23) +1 8230 а на самом деле неудобно даже это , arisu (ok), 11:20 , 17-Фев-12, (28) Хорошее начинание Когда разовьют немного, будет очень удобно пользоваться А по, lucentcode (ok), 19:01 , 16-Фев-12, (7) +2 Не внимательно читаем Скорость сборки выше, гибкость для каких-то магических де, Аноним (-), 19:08 , 16-Фев-12, (9) // Это вообще разные уровни для начала , Sauron (??), 23:14 , 16-Фев-12, (21) +1 очень люблю QMake, а теперь уже что-то более языко-независимое выплывает - я тол, добрый дядя (?), 23:13 , 16-Фев-12, (20) +3 Такс, а что мешало qmake и раньше использовать для сборки обычных C C приложен, Sauron (??), 23:18 , 16-Фев-12, (22) +2 // ничего не мешало, я давно уже qmake юзаю для любых C прог как нормальную беспр, добрый дядя (?), 23:44 , 16-Фев-12, (24) // qmake - очень слабенькая система сборки посравнению с аналогами Если проект под, green (??), 12:22 , 17-Фев-12, (30) // qmake давно это умеет, только реализовано немного кривовато каталог сборки не м, annulen (?), 13:26 , 17-Фев-12, (32) Да знаю о таком функционале Но снова таки слабенько Сборка происходет в папке , green (??), 13:35 , 17-Фев-12, (33) кстати, а зачем вот у меня jam, например, складывает объектники в спецкаталог, , arisu (ok), 14:32 , 17-Фев-12, (36) из долгих обсуждений в их бложеге я в своё время так и не понял, чем им не понра, arisu (ok), 11:18 , 17-Фев-12, (27) // представь что у нас есть человек который освоил js и qml и написал программу, а , Аноним (-), 01:14 , 22-Фев-12, (55) // неа не получается , arisu (ok), 01:15 , 22-Фев-12, (56) Используйте Premake Декларативный синтаксис еще более лаконичен, плюс поддержка, annulen (?), 13:25 , 17-Фев-12, (31) // а ты бы почитал причины, по которым 171 генераторы makefile-сов 187 были заб, arisu (ok), 14:39 , 17-Фев-12, (37)   // Если ты про пункт Build directly from tool , то он полон взаимоисключающих пара, annulen (?), 16:24 , 17-Фев-12, (38)   // нет, я про то, что make не видит проект, раскиданый по каталогам, как одно целое, arisu (ok), 17:40 , 17-Фев-12, (39)   Совершенно бессмысленный аргумент В той статье написано, что рекурсивный мейк н, annulen (ok), 17:51 , 17-Фев-12, (40) +1   это туда, в нокию им осталось сделать ещё жажок и убрать слово 171 рекурсивный, arisu (ok), 17:55 , 17-Фев-12, (41)   Интересная логическая цепочка рекурсиный мейк не нужен - так не используй ег, annulen (ok), 18:11 , 17-Фев-12, (42)   вообще-то 171 make не нужен 187 8212 это моя аксиома понятно, что отсда , arisu (ok), 19:09 , 17-Фев-12, (44)   У ninja цель совершенно четкая - отделить построение DAG целей сборки и их выпол, annulen (ok), 18:18 , 17-Фев-12, (43)   это мы уже проходили, autocrap называется для больших проектов конфигуратор мож, arisu (ok), 19:12 , 17-Фев-12, (45)   Виденная критика была местами крива сама по себе Впрочем, обстоятельно сейчас , Michael Shigorin (ok), 19:31 , 17-Фев-12, (47)   ну, кое-как, с матами и воплями оно костылится так же, как костылится просчёт за, arisu (ok), 19:43 , 17-Фев-12, (48)   Просчет зависимостей делает компилятор и генерерует d файлы, достаточно его об , annulen (ok), 20:08 , 17-Фев-12, (50)   это неудобно, хотя и точнее, чем можно сделать в билд-системе и медленней, кста, arisu (ok), 20:20 , 17-Фев-12, (52)   замержить бы их идеи с вашими , Аноним (-), 01:16 , 22-Фев-12, (57) 4,7,9,20,22,27,31

Сообщения

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

	37. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от arisu (ok), 17-Фев-12, 14:39
	> Используйте Premake а ты бы почитал причины, по которым «генераторы makefile-сов» были забракованы, что ли. сам по себе premake хорош, но вот формой не подходит.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от annulen (?), 17-Фев-12, 16:24
	Если ты про пункт "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" и "не наши имена в копирайтах".
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от arisu (ok), 17-Фев-12, 17:40
	> Если ты про пункт "Build directly from tool" нет, я про то, что make не видит проект, раскиданый по каталогам, как одно целое. уж кто только не ругался на рекурсивные вызовы make в подкаталогах. это пытаются полечить костылями разной степени уродливости, но нафэйхоа? намного проще не использовать make.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Разработчики Qt представили инструментарий для сборки..."	+1 +/–
	Сообщение от annulen (ok), 17-Фев-12, 17:51
	Совершенно бессмысленный аргумент. В той статье написано, что рекурсивный мейк не нужен. Так генерите нерекурсивные мейкфалы, и будет вам Щастье. Нет, блин, все пытаются свой мейк для этого написать. Из всех проектов по замене мейка внимания заслуживает только ninja.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от arisu (ok), 17-Фев-12, 17:55
	> Совершенно бессмысленный аргумент. это туда, в нокию. > В той статье написано, что рекурсивный мейк не нужен. им осталось сделать ещё жажок и убрать слово «рекурсивный». > Нет, блин, все пытаются свой мейк для этого написать. далеко не только для этого, сия фича — просто вкусный бонус. > Из всех проектов по замене мейка внимания заслуживает только ninja. у make обнаружился Фатальный Недостаток, ага. это я намекаю, что «замена make» не нужна, равно как и сам make. а нинзя — это не пришей системе шлейф какой-то.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от annulen (ok), 17-Фев-12, 18:11
	Интересная логическая цепочка: "рекурсиный мейк не нужен" - "так не используй его через ж^W^W рекурсивно" - "да наплевать, все равно мейк не нужен".
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от arisu (ok), 17-Фев-12, 19:09
	> Интересная логическая цепочка: «рекурсиный мейк не нужен» — "так не используй его > через ж^W^W рекурсивно" — «да наплевать, все равно мейк не нужен». вообще-то «make не нужен» — это моя аксиома. понятно, что отсда следует, что не нужен никакой.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от annulen (ok), 17-Фев-12, 18:18
	У ninja цель совершенно четкая - отделить построение DAG целей сборки и их выполнение от любых "конфигурационных" действий, чем страдает мейк. Конфигуратор делает свою работу, а нинзя - свою.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	45. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от arisu (ok), 17-Фев-12, 19:12
	> У ninja цель совершенно четкая — отделить построение DAG целей сборки и > их выполнение от любых «конфигурационных» действий, чем страдает мейк. Конфигуратор делает > свою работу, а нинзя — свою. это мы уже проходили, autocrap называется. для больших проектов конфигуратор может генерить что угодно вообще, а для средних и мелких лучше иметь возможность обойтись одним инструментом. впрочем, если кто-то не может жить без конфигураторов (которые иногда больше, чем исходники всего проекта), то кто я такой, чтобы запрещать?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от Michael Shigorin (ok), 17-Фев-12, 19:31
	> нет, я про то, что make не видит проект, раскиданый по каталогам, > как одно целое. уж кто только не ругался на рекурсивные вызовы > make в подкаталогах. Виденная критика была местами крива сама по себе.  Впрочем, обстоятельно сейчас не расскажу.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	48. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от arisu (ok), 17-Фев-12, 19:43
	> Виденная критика была местами крива сама по себе.  Впрочем, обстоятельно сейчас > не расскажу. ну, кое-как, с матами и воплями оно костылится. так же, как костылится просчёт зависимостей (уж простейшие-то include система может и сама просканировать, я что, дятел — долбить ей это или костыли дёргать?). а уж про «проект — это все *.c в каталоге исходников» (опять же, с просчётом зависимостей и ты пы)… не, не будем о грустном. тот же Jam делает подобное несколькими строками. и вообще мал, реактивен (в плане скорости), удобен. для проектов среднего уровня можно его использовать и как конфигуратор заодно. да-да, я фанат jam'а, если кто ещё не заметил. и ниасилятор всего остального.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от annulen (ok), 17-Фев-12, 20:08
	Просчет зависимостей делает компилятор и генерерует .d файлы, достаточно его об это попросить. Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо рекурсивных вызовов.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Разработчики Qt представили инструментарий для сборки..."	+/–
	Сообщение от arisu (ok), 17-Фев-12, 20:20
	> Просчет зависимостей делает компилятор и генерерует .d файлы это неудобно, хотя и точнее, чем можно сделать в билд-системе. и медленней, кстати. помимо прочего, на свете есть не только два языка и один компилятор. > Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо > рекурсивных вызовов. недостаточно, если я хочу, например, разные значения переменных для разных каталогов (или вообще для разных целей в одном). не то, чтобы этого совсем нельзя было сделать, но… нененене, только за большие деньги. ну право, это бессмысленный спор: не предназначен make для ручного написания, если более-менее сложный проект собираешь. да, мэйкфайлы можно генерировать — но не проще ли тогда сделать ещё один логичный шаг и обучить генератор оставшимся функциям? ещё раз ткну пальцем в сторону jam, как весьма неплохой реализации билд-системы. да, кстати: за табуляторы отдельный плевок. я понимаю, что «нечаянно получилось», но от этого оно приятней не становится.
	Ответить | Правка | Наверх | Cообщить модератору

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

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