| |
| 2.4, Аноним (-), 21:32, 31/05/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
Хотя бы тем что не на жаве. Но вместе они не нужны, потому что есть cmake.
| | |
| |
| |
| 4.22, Аноним (-), 04:58, 01/06/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да это еще куда ни шло. А вот определение либ на платформе, свойств платформы и прочая - глюкастое донельзя. В этом плане его спокойно зарулят даже древние автотулсы.
| | |
| |
| 5.56, Лентяй (??), 18:41, 05/06/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Да это еще куда ни шло. А вот определение либ на платформе,
> свойств платформы и прочая - глюкастое донельзя. В этом плане его
> спокойно зарулят даже древние автотулсы.
Зарулят? Ну-ну. В CMake изначально решены проблемы (ну или сильно затрднены пути создания таковых) с неправильным порядком ключей -I и -L, например. Немало проектов на autotools, особенно крупных, не собирается правильно при наличии уже установленной в системе копии. В CMake такого добиться ещё надо постараться (в OpenCV 2.4, например, умудрились).
Плюс, язык CMake куда очевиднее, чем m4 или шелл.
Насчёт же определения свойств платформы - patches are welcome, разработчики весьма отзывчивы. Всё-таки проект заметно моложе autotools, поэтому не удивительно, что количество поддерживаемых платформ (и то, относительно экзотических) меньше.
| | |
| |
| 6.58, arisu (ok), 04:38, 06/06/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Немало проектов на autotools, особенно крупных, не собирается правильно при наличии уже
> установленной в системе копии.
их авторов надо бить молотками по головам. фиче «сначала ищем несисемный инклюд в каталоге собираемого исходника» сто лет в обед. если проект при сборке инклюдит свои файлы как системные… это уже даже не прискорбно, это неоперабельно. исходники-то пропатчить можно, а как мозги авторам починить?
| | |
| |
| 7.59, Лентяй (??), 04:53, 06/06/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Немало проектов на autotools, особенно крупных, не собирается правильно при наличии уже
>> установленной в системе копии.
> их авторов надо бить молотками по головам. фиче «сначала ищем несисемный инклюд
> в каталоге собираемого исходника» сто лет в обед. если проект при
> сборке инклюдит свои файлы как системные… это уже даже не прискорбно,
> это неоперабельно. исходники-то пропатчить можно, а как мозги авторам починить?
Хотите - верьте, хотите - нет, но вот лично я недавно получил ответ в духе "сам дурак, убери старые либы из системы и всё соберётся как надо", когда запостил в багтрекер Samba4 жалобу на такую проблему. Там, правда, сильно переделанный WAF, а не autotools, но суть та же, и очень уж пример яркий.
Причём, что самое смешное, кто-то из авторов изначального кода WAF даже оставил комментарий, мол, надо быть внимательнее с порядком опций -L - то есть вменяемые люди есть. Но со временем они куда-то деваются...
| | |
| |
| 8.63, arisu (ok), 05:16, 06/06/2013 [^] [^^] [^^^] [ответить] | +2 +/– | да я так, 171 в общем негодую 187 я тоже подобное встречал, и вроде бы у лю... текст свёрнут, показать | | |
| |
| 9.64, Лентяй (??), 01:26, 07/06/2013 [^] [^^] [^^^] [ответить] | –1 +/– | Дык что самое-то обидное - предлагаешь патч, который решает эту проблему, а его ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| |
| |
| 4.23, Аноним (-), 04:59, 01/06/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> да какой он на хрен программист?
Ну как какой? Быдлокодер обыкновенный, одна штука.
| | |
|
| |
| 4.32, BayaN (ok), 15:23, 01/06/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
 О..еть, по этому бреду даже статьи пишут. CERN научились бюджеты пилить, молодцы.
| | |
| |
| 5.33, Dmitry77 (ok), 15:38, 01/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Что мне нравится в maven - перед компиляцией он может сам скачивать всё дерево зависимостей, причём это кроссплатформенно: под любым линуксом, виндой, макосью.
Я на С++ не пишу, но как я понимаю для с++ такое нельзя:
все зависимости управляются менеджером пакетов дистрибутива, у каждого дистрибутива менеджер пакетов свой, пакеты называются по разному.
| | |
| |
| 6.34, Карбофос (ok), 19:34, 01/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
 >у каждого дистрибутива менеджер пакетов свой
не всё так печально, все дебиан-базированные (Ubuntu и т.п.) на dpkg, Fedora, OpenSuse - rpm, ну и плюс пару дистров, базированных на Slackware и подобных. зависимости пакетов вытягиваются командами, в самих пакетах есть эта инфа, если пакет не содержит только статически собранные программы и конфиги. такое тоже бывает. так что написать что-то в этом духе для большинства дистрибутивов - не шибко сложно. и это не является свойством какого-то языка программирования. большинство проектов просто выдают ошибку, если какой-то devel пакет доустановить надо.
| | |
| 6.57, Лентяй (??), 18:45, 05/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Что мне нравится в maven - перед компиляцией он может сам скачивать
> всё дерево зависимостей, причём это кроссплатформенно: под любым линуксом, виндой,
> макосью.
> Я на С++ не пишу, но как я понимаю для с++ такое
> нельзя:
> все зависимости управляются менеджером пакетов дистрибутива, у каждого дистрибутива менеджер
> пакетов свой, пакеты называются по разному.
Оборотная сторона - Maven усложняет сторонний контроль процесса сборки и поэтому хорош для машины разработчика, на начальном и основном этапах разработки. Как только речь заходит о подготовке релиза - "умность" Maven, WAF, Ruby bundler и тому подобных приходится выключать, чтобы полностью контролировать среду сборки и благодаря этому иметь возможность получать стабильные результаты сборки.
| | |
|
| 5.40, Аноним (-), 13:04, 02/06/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
авторы статьи - скорее всего просто студенты, проходившие практику в ЦЕРНе и написавшие курсач по этой теме. Очень плохо себе представляю специалиста, занятого гибридизацией мейка и мавена вместо реализации алгоритмов из вычислительной физики и математики, ну или чем они там занимаются))
| | |
|
|
|
| 2.26, arisu (ok), 08:53, 01/06/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Чем это лучше Apache Maven?
любая система сборки, которая не требует ставить говножабу, уже лучше. даже sh.
| | |
|
| |
| 2.5, Аноним (-), 21:33, 31/05/2013 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Чем это лучше cmake?
Ничем, разумеется. Но наверняка лучше кривого qmake.
| | |
| |
| 3.6, попо (?), 21:34, 31/05/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
Хотя я прочитал статью, cmake делает makefile, а это чудо нет. Стоит его попробывать
| | |
|
| 2.13, неанонимус (?), 23:10, 31/05/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
Как ниже заметили, нет вызовов промежуточных тулзов (будь то make или что ещё), как следствие, сборка идет гораздо быстрее (все помним, что рекурсивные мейкфайлы - зло?).
Ну и возможность писать ф-ии на джаваскрипте в разы лучше синтаксиса симейка. Работа со строками в симейке - это та еще попоболь.
Вообще синтаксис симейка ужасен для системы сборки, имхо.
| | |
| |
| |
| 4.31, anon2 (?), 14:52, 01/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
>>все помним, что рекурсивные мейкфайлы - зло?
> Не помню. Почему?
Потому что не позволяют построить полное и единственное дерево зависимостей на весь проект, а без такого дерева невозможно эффективно распараллелить сборку.
Сам сделал такую систему сборки, основанную на gnu make - рекурсивно зачитываются все Makefile'лы через директивы include, сроится полное дерево зависимостей и выполняется сборка: сначала параллельно собираются все исходники, потом параллельно линкуются все либы, затем также параллельно линкуются все исполняемые файлы. Достигается идеальная масштабируемость на любое количество cpu - когда при сборке все cpu загружены на 100%.
| | |
| |
| |
| 6.36, Ytch (ok), 23:58, 01/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
 >и ты посмотри в сторону jam. может понравится.
jam штука хорошая. Кстати, спасибо что в свое время "навёл" на него. Когда дерево представляет собой один проект - удобен сильно (даже при наличии богатой фантазии в части вариантов сборки). Когда дерево - это несколько проектов с пересекающимися общими частями, но которые надо собирать частично по-разному в зависимости от текущего собираемого проекта, добавляется немного трюкачества, впрочем, в конечном итоге все решаемо оказалось. Правда Jamfiles слегка потеряли свою простоту и "прозрачность", но в любом случае сложней Makefile'ов для тех же проектов все равно не стали. ))
| | |
| |
| 7.37, arisu (ok), 00:42, 02/06/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Кстати, спасибо что в свое время «навёл» на него.
рад, что кому-то помогло.
| | |
|
| 6.38, anon2 (?), 07:51, 02/06/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> и ты посмотри в сторону jam. может понравится.
да, интересный проект, только вызывает сомнение автоматическое построение зависимостей через рекурсивный скан хедеров.
во-первых, теряется время сборки,
во-вторых не факт, что зависимости вычисляются правильно - только компилятор (точнее препроцессор) точно знает какие хедера были подключены при компиляции. Не все компиляторы могут выдавать такую информацию - gcc может.
У себя пока зависимости от хедеров не вычисляю - мне важна скорость сборки с нуля, поэтому процесс сборки разбит на две части: генерация общих хедеров, которые могут включаться где угодно, а потом уже сборка всего остального.
кстати, пример моего Makefile'а
include $(TOP)/make/make_header.mk
DLL := eventmgr
DEFINES += THREAD_COUNT=10 $(if $(filter TARGET_GATE%,$(DEFINES)),THREAD_COUNT_EXTEND=10)
INCLUDE += $(TOP)/common/sdiag
SRC := sk_pool.cpp th_pool.cpp timeserv.cpp eventmgr.cpp
DLLS := diagnose
DEFINES_WINXX := USE_WINSOCK2
USE_LINUX := pthread
USE_WINXX := ws2
USE_SOLARIS := socket
include $(TOP)/make/make_default.mk
| | |
| |
| 7.41, arisu (ok), 20:12, 02/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
> только вызывает сомнение автоматическое построение зависимостей
> через рекурсивный скан хедеров.
пока что, за кучу лет использования в проектах разных размеров, проблем не было. разве что может лишнюю зависимость посчитать — но это не так уж страшно.
> во-первых, теряется время сборки
даже в стандартном варианте jam делает всё это *очень* быстро. но для тех, кому всё-таки медленно — есть патчик (гуглится несложно), который кэширует выхлоп сканера.
> У себя пока зависимости от хедеров не вычисляю — мне важна скорость
> сборки с нуля
мне, честно говоря, важна скорость сборки всегда. но важнее скорости — адекватность языка сборщика. jam мне показался намного более нормальным, нежели make. и, конечно, поддержка подкаталогов из коробки.
впрочем, я вдобавок использую сильно модифицированый Jambase. ну, то там правило добавил, то там правило поправил — так и выросло.
> кстати, пример моего Makefile'а
тоже неплохо. если постараться, make можно превратить в «почти jam». :3
| | |
| |
| 8.60, Лентяй (??), 04:57, 06/06/2013 [^] [^^] [^^^] [ответить] | +/– | Это, например, страшно при пакетной сборке, когда пакет, являющийся псевдо-завис... текст свёрнут, показать | | |
| |
| 9.61, Лентяй (??), 04:58, 06/06/2013 [^] [^^] [^^^] [ответить] | –1 +/– | Кстати, как раз из-за нечестного сканера зависимостей очень хочется как раз по... текст свёрнут, показать | | |
| 9.62, arisu (ok), 05:12, 06/06/2013 [^] [^^] [^^^] [ответить] | +1 +/– | при чём тут 171 пакеты 187 и откуда это вообще взялось в обсуждении хинт у... текст свёрнут, показать | | |
| |
| 10.66, Лентяй (??), 00:05, 08/06/2013 [^] [^^] [^^^] [ответить] | +/– | Очень даже причём Подразумевалась массовая сборка пакетов, которые используют в... большой текст свёрнут, показать | | |
| |
| 11.68, arisu (ok), 09:33, 08/06/2013 [^] [^^] [^^^] [ответить] | +/– | возможно, это подразумевалось тобой остальные в этой ветке говорили совсем о ... текст свёрнут, показать | | |
|
|
|
|
| 7.42, arisu (ok), 20:14, 02/06/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
p.s. главное — boost-jam не бери. это ужас, летящий на крыльях ночи. у бустовцев серьёзное ООП гойловного моска: они пихают недоООП даже туда, где это нафиг не надо.
а вот всякие патчи к перфорсовскому оригиналу посмотреть стоит.
| | |
|
|
|
|
|
|
| |
| |
| 3.9, попо (?), 21:50, 31/05/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну видать решили не парится и взяли основу языка от QML. Зачем там другие языки? Да и в qbs называют, что отдельный язык для qmake был его фатальным недостатком.
| | |
|
|
| 1.16, хрюкотающий зелюк (?), 00:24, 01/06/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Вопрос: про Qt что оно "требовать скрипт configure и небезызвестный syncqt", это относится к сборки самого Qt как такового?
А свои программы собирай-конпеляй при помощи QBS? И ничего более?
| | |
| |
| 2.18, попо (?), 00:30, 01/06/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Там писали, что если сейчас использовать qbs для сборки Qt, то без configure & syncqt не обойтись. А авторы qbs этого не хотят, и они планируют расширить функционал qbs, чтобы можно было обойтись без других инструментов.
| | |
|
| 1.20, Аноним (-), 04:25, 01/06/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Очень удобная система, конфигурационные скрипты писать и поддерживать одно удовольствие. Собирает шустрее других систем.
Свои проекты внутренние перевел на нее, из QtC пока не собираю еще (использую qmake), но когда нужно сделать полную сборку всех проектов для деплоя, использую qbs.
Так же написал для него скрипты сборки старых дельфевых проектов. Что очень экономит время на запуск ide =)
| | |
| |
| |
| 3.25, Аноним (-), 07:44, 01/06/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
я уже боюсь представить что вы скажете, узнав про проекты на фортране =)
наследие примерно четверть века тянется, не все вот так сразу можно переписать на плюсах и qt.
| | |
| |
| 4.45, Аноним (-), 11:45, 03/06/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> я уже боюсь представить что вы скажете, узнав про проекты на фортране =)
"Вы неплохо сохранились" :)
> наследие примерно четверть века тянется, не все вот так сразу можно переписать
> на плюсах и qt.
Наследие некроманов - куда ни шло, а вот разучивать дельфей в 2013 году - вот это странное начинание, да.
| | |
| |
| 5.46, arisu (ok), 11:53, 03/06/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> а вот разучивать дельфей в 2013 году — вот это странное начинание, да.
с чего бы? язык весьма неплохой.
| | |
|
|
| 3.39, maximnik0 (?), 13:03, 02/06/2013 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Necromancy is a forbidden art.
Какая некромантия -2012 год это некромантия ? Видел на диске к хакеру за 12 год , версия для студентов шла за 35 уе ,начальная базовая 90-120 уе ,ентерпрайз 1200 -5000 уе , так что не погоже что труп . Хотя от старого делфи там очень мало -портировали все что могли на платформу NET (во внутренястях не разберался -просто просмотрел и удалил ,Qt и кросплатформенного движка уже нет :-( )
.
| | |
| |
| 4.44, Аноним (-), 11:44, 03/06/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Какая, какая дельфи нынче пользуются только убежденные некроманы Остальные ... большой текст свёрнут, показать | | |
| |
| 5.47, maximnik0 (?), 12:26, 03/06/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А он там был когда-то? А так что куть, что дотнет -
Да когдато QT был в делфи 7 -работал через кросc платформенный библиотеку CLX , был даже делфи портирован под линукс (Kulix 3 ),1 и 2 версия работала через wine .
//Насколько я знаю библиотеку CLX перенесли на Лазариус ,и этой библиотеке пофиг что там за графические либы (win32 ,QT (2-3-4) ,GTK ,FTL ) ,приложение скомпилируется с любой из библиотек ,жаль что CLX забросили .
| | |
| |
| 6.48, arisu (ok), 12:29, 03/06/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
это ж надо уметь и так неграмотно писать, и так задорно смешивать факты с фантазией… даже немного завидую.
| | |
| |
| 7.49, хрюкотающий зелюк (?), 15:29, 03/06/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
А он и не наврал - раньше "дельфи для линукс" именно что базировался поверх Qt, просто совместимость между ОС. Сейчас, в свете LGPLного Qt это никому не нужно, и CLX в том числе.
| | |
| |
| 8.50, arisu (ok), 15:40, 03/06/2013 [^] [^^] [^^^] [ответить] | +1 +/– | ещё как наврал QuickTime там вообще не при чём это раз никто никуда CLX не ... текст свёрнут, показать | | |
| |
| |
| 10.55, arisu (ok), 00:27, 04/06/2013 [^] [^^] [^^^] [ответить] | +1 +/– | ты извини за наезд, просто очень пост провоцирующий я-то понял, что ты сказать ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| 1.43, Loooooker (ok), 20:35, 02/06/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Если я захочу перевести свои наработки на это, мне все cmake-скрипты на qml переписывать что ли?
| | |
| |
| 2.51, Аноним (-), 16:36, 03/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
если ты захочешь перенести на любую другую систему сборки, тебе переписывать придется. если эти велосипеды понадобятся, конечно.
| | |
|
|
