... а кончится это тем, что каждая софтина буит со своим методом генерации мэйк-файла :(

Просто рябятам надоело трахаться с автомейком

Но сам по себе autoconf (automake/libtool) - кривулька страшная. Особенно если так что-либо на перекосяк идет.

Re:

Не плакайте, maxcom, все намана :-). Если руку набить - .am/.ac щелкаются как орехи :-).

Хотя, конечно, может, троллтеки и придумали что-то более ... прозрачное и умное. Только все равно, из-за широкой распространенности autotools отказаться от них в обозримом будущем все равно не удастся...

Если кроме линукса ничего не видел и пишешь приложения только для оного -- таки да, щелкаются как орехи.

Ну да, ну кривизна. Но уже родная и привычная кривизна (как Линус там сказал про asm86? "charming oddities" - так и тут). А при том, что куча 3rd-party libs живет на автотулзах (включая почти весь fd.o - в него КДЕ пока играет, вроде) - введение альтернативной системы конфигурирования как-то попахивает умножением сущностей без нужды...

> Несмотря на то, что он идет в поставке с Qt, он не требует для своей работы наличия этой библиотеки и может с успехом использоваться для сборки не-Qt проектов.

Угу, а лицензия, лицензия на него какая? не такая-же, как на QT?

Такая же как и на все тулзы из QT. То есть двойная. А вообще qmake имхо гораздо удобнее и проще в использовании.

>Угу, а лицензия, лицензия на него какая? не такая-же, как на QT?

А тебя бы не устроила лицензия GPL для прикладной софтины? Кажется ты чего-то недопонял...

Вообще кто бы реанимировал ODE make - действительно крутая вещь, причём с лицензией BSD. Было бы здорово. А autotools достали уже своей базовой идеей - создавать разные Makefile'ы под разные платформы и утилиты make. Из опыта - такой подход существенно не помогает, только время отнимает компьютерное.

Будем считать что make- это ассемблер маке файлов. Вредположим что automake похож на command.com, то на что похож qmake на С, perl или java?

> Будем считать что make- это ассемблер маке файлов. Вредположим что automake похож на command.com, то на что похож qmake на С, perl или java?

На xml. Большой xml.

>Вообще кто бы реанимировал ODE make - действительно крутая вещь, причём с лицензией BSD.

Поэтому он и умер. Все не GPL проги трупы в зародыше. Если хочеш чтобы, прога жила, Открой ее и она будет жить вечно.

>>Вообще кто бы реанимировал ODE make - действительно крутая вещь, >>причём с лицензией BSD. >Поэтому он и умер. Все не GPL проги трупы в зародыше. Если хочеш >чтобы, прога жила, Открой ее и она будет жить вечно. Да, это уже клиника.

Скорее всего именно такие "пропагандисты свободы" и клонируют(тырят) под ГПЛ всё что ни попадётся.

>На xml. Большой xml.

Ну неправда - на Prolog, что ли :)

Забавно как люди собираются пользоваться qmake в таком большом проекте, когда этот самый qmake не позволяет задавать флаги компиляции, оптимизации и линковки... Или позволяет каким-то тайным способом?

> при том, что куча 3rd-party libs живет на автотулзах (включая почти весь fd.o - в него КДЕ пока играет, вроде) - введение альтернативной системы конфигурирования как-то попахивает умножением сущностей без нужды...

Дело в том, что он используется для сборки самого Qt и всех тулзов и примеров из стандартной поставки. Так что от него никуда не убежать, но можно его более эффективно использовать.

> Если кроме линукса ничего не видел и пишешь приложения только для оного -- таки да, щелкаются как орехи.

Мы используем autotools в проектах под Linux, FreeBSD и OpenBSD - есть иногда некоторый геморой, но в общем и целом - полёт нормальный.

Т.е. КДЕшники УЖЕ сидят на двух стульях? И как бы они ни ерзали - им на них сидеть до тех пор, пока троллы не перейдут на автотулзы (или, что еще менее верятно, fd.o перейдет на qmake:). Мда. И почему мне их не жалко?:)

Ну как, libtool хорош на OpenBSD? ;-)

> Или позволяет каким-то тайным способом?

Как раз таки более понятным способом, чем autotools. По крайней мере, пока в autotools руку не набьешь. А заодно и морду :)

А никто не пробовал такую замечательную штуку как scons (http://www.scons.org)? По простоте она уделывает autotools точно, да и по функциональности не сильно проигрывает, точнее при знании Python не проигрывает вообще...

>>>Вообще кто бы реанимировал ODE make - действительно крутая вещь, >>причём с лицензией BSD. >Поэтому он и умер. Все не GPL проги трупы в зародыше. Если хочеш >чтобы, прога жила, Открой ее и она будет жить вечно. Да, это уже клиника.

>Скорее всего именно такие "пропагандисты свободы" и клонируют(тырят) под ГПЛ всё что ни попадётся.

Не нуно пустых слов и безадреснных и безфактных реплик.

qmake не имеет достаточной функциональности, чтобы можно было собирать им KDE, но он прост и удобен для сборки приложений под KDE. Никто, собственно, и не предлагал собирать qmake'ом KDE (см. http://www.kdedevelopers.org/node/view/647). Есть желание только поддержать разработчиков программ для KDE, предоставляя возможность использовать простой и нетребовательный инструмент. Для сравнения, простой проект приложения под KDE (C++, autotools) включает ~1M дополнительных файлов для обслуживания autotools. Аналогичный проект C++/qmake содержит всего лишь 2 .pro файла размером ~1K ;) Не стоит забывать, что большая часть разработчиков понимает только процесс работы с Makefile.am, но не с configure.ac (либо подобными).

>qmake не позволяет задавать флаги компиляции, оптимизации и линковки... Или позволяет каким-то тайным способом?

Почему же, позволяет, например флаги компиляции вот так:
win32{
win32-msvc.net:{
QMAKE_CXXFLAGS_RELEASE += /Zc:forScope
QMAKE_CXXFLAGS_DEBUG += /Zc:forScope
}

флаги линковки указываются в QMAKE_LFLAGS_RELEASE, QMAKE_LFLAGS_DEBUG и им подобных.

Способ не тайный... assistant поможет ;)

>Забавно как люди собираются пользоваться qmake в таком большом проекте, когда этот самый qmake не позволяет задавать флаги компиляции, оптимизации и линковки... Или позволяет каким-то тайным способом?

Позволяет. И очень просто... RTFM таки или как?

>>На xml. Большой xml.

>Ну неправда - на Prolog, что ли :)

Гм а make не похож на пролог? Вроде теже входные условия и действия, xml скорее похож на дерево.

Re:

Таки нет.

У меня есть опыт писания autoconf макросов, портабельных, по крайней мере, между Linux и MinGW/Cygwin (и, включавших, между прочим, тесты на подключение ораклячих (8,9) и ACE/TAO библиотек).

Ну и следование общим sh-portability guidelines дает надежду на то, что, по крайней мере, между x86-системами макросы получались переносимыми (за другие платформы не скажу, потому как, вполне вероятно, не все неоходимые проверки делались). Тяжеловесно, конечно, слегка, но вполне алгоритмично (в смысле, анализируется путем последовательного биения на составляющие).

Re:

Меня - нет. Потому что в autotools специально оговаривается несколько исключений, делающих возможным их использование в проприетарном софте.

Re:

Наверное, потому же, почему нам не жалко тех, кто судорожно мечется между выбором базового языка программирования для своего проекта, недавно отметившего выход версии 2.8 <evil grin> :-))

Re:

Я, в целом, целиком и полностью ( ;-)) ) за написание ПО на питоне :-))

Однако ж, незадача имеется. Поскольку подавляющее большинство софта идет именно с /usr/share/aclocal/smth_test.m4 на борту, а не с чем-то еще, то использовать этот scons (равно как и qmake) в его нынешнем состоянии в прикладном софте - довольно натужное занятие. Нужно, чтобы авторы всех этих бесчисленных /usr/lib/libsmth.so c моего винта почесались перед этим.

К тому же, .ac-макросы - это, в основном, декларативное "программирование", срывающееся на "позорную императивщину" (C) vsl@ только в крайних случаях (то есть, когда _действительно_ нужно упасть на уровень sh-скрипта и начать там что-то судорожно вычислять).

scons вполне _мог_ бы быть реализован в том же стиле (питон позволяет), однако, из того, что я вижу в его User Docs, они, увы, не пошли по этому пути, что автоматически снижает его ценность [для меня] в разы. В конце концов, [мне] - программу программировать, а не конфигурационные скрипты к ней.

Re:

Судя по тому, что написано в a_kde_app-x.y.z/admin/, бОльшая часть KDE-девелоперов, даже из "Core", не понимает того, что делать с этими .ac и прочими acinclude.m4 ;-)

Так оно и есть ;) Немногие имеют смелость посвятить месяцы изучению системы сборки, потому как резонно предполагают, что сложность системы сборки _не_ _должна_ превышать сложность создаваемой программы.

Я не хочу "обижать" autotools, они выполняют действительно важные задачи. Только их сложность является предметом обсуждения.

PS: причем IDE не в состоянии упростить жизнь разработчику. Так, например, IDE может обслуживать все необходимое для automake, но кардинально упростить жизнь пользователям autoconf никакая среда не сможет.

Да, доп. файлов autotools запихивают море - это научный факт (ну, можно немножко уменьшить за счет foreign - но это все слезы). Но зато какая гибкость! Вообще, мысль про то, что кто-то понимает Makefile.am и не понимает configure.ac - новая. Я думал, что оно как-то в одном флаконе идет. Вообще, чтобы человек прочувствовал всю эту машинерию - надо просто дать ему поиграться с m4 в полный рост - оно как-то мозги прочищает:)

Ой, что это вы так долго спали? С ранних версий в гноме базовый язык С - за что и любим и ценим. Номер версии, кстати, вообще не признак ничего - лучше уж просто человеко-года посчитать, если хотите заклеймить....

А если Вы про недавнюю дискуссию, то это базовый язык для быстрой разработки приложений (и, заметьте, это проходит в форме открытого обсуждения в мейллистах, а не диктата со стороны фирмы-производителя базового тулкита).

Это да. Ахиллесова пята автотулзов - поддержка от IDE. GUIфицировать разработку проектов с автотулзами - это примерно как заставить дизайнеров, привыкших к визуальному редактированию HTML - делать сайты при помощи xslt...

>это базовый язык для быстрой разработки приложений

LOL

Язык для быстрой разработки

Учитывая темпы развития гнома вполне можно в качестве языка для быстрой разработки и ассемблер использовать :-))

Re:

> С ранних версий в гноме базовый язык С...

Хех.. С ранних-то с ранних, да только некоторые, э-э-э, "евангелисты", типа Хавока так таки и мечутся, что тот Вицин между Моргуновым и Никулиным в "Кавказской пленнице": то ли всем на яву ползти, то ли на .NET ;-))

> Номер версии, кстати, вообще не признак ничего - лучше уж просто человеко-года посчитать, если хотите заклеймить....

Зато адресует точно в цель :-).

> А если Вы про недавнюю дискуссию, то это базовый язык для быстрой разработки приложений (и, заметьте, это проходит в форме открытого обсуждения в мейллистах, а не диктата со стороны фирмы-производителя базового тулкита).

По поводу свободы выбора гном мне напоминает "мы посоветовались, и я решил". Сколько было воплей по поводу того, что-де "не убирайте наш любимый shortcut sidebar из evo-2!". Сам писал, как только-только первые скриншоты (даже не беты еще) появились. Толку чуть. При том, что функциональность с новым подходом _очевидно_ зарезалась (я, н-р, имел обыкновение выносить туда конкретные "выделенные" ящики почтовые для быстрого доступа и наглядного обзора, куда собственно arrived этот самый new mail). И так со всем. Фтопку, в общем, такую демократию.

А насчет "диктата со стороны производителя тулкита" - это, извините, ерунда. Под Qt/KDE сейчас едва ли не больше привязок для различных языков, чем под GNOME. Ну, разве что, plain C, хоть и возможен, но ... неадекватен :-).

"Евангелисты" действительно пытаются выбрать наименьшее из зол - причем процесс идет тяжко, это правда - в частности, потому что ни одна коммерческая компания не может скажать "ша, уроды, я сказал - значит, будет так" (хотя Новел уже объявил Моно внутренним стандартом, вроде). Но вот покажите мне обсуждение выбора "плюсов" компанией Толлтех? У меня лично впечатление, что это было сделано административно-командным путем...

По поводу демократии - да, она скорее меритократия+власть денег (хотя, конкретно про сайдбар ничего сказать не могу - этой драки я не видел). Но, во всяком случае, процесс является публичным - что уже лучше того, что мы можем получить от Троллей.

Насчет привязок языков - я не буду спорить, что у gtk их больше (может, это и не так) - но хотелось бы знать, откуда сведения, что qt лидирует по привязкам? Да, есть ли у kde программа централизованных релизов разных bindings, как у гнома? И я уж точно не буду комментировать отсутствие привязки к "главному языку униха" - об этом говорено-переговорено тут уже...

ЗЫ Номер версии, кстати, никуда не адресует - в отличие от человеко-лет, которых у гнома действительно немало.

Что не так с темпами развития? Пока что те, кто вкладывают деньги - ими довольны:)

кстати, bsd более свободная чем gpl - можно форкунуть и закрыть проект =)... а gpl... странная штука это gpl... открытость исходных кодов дошедшая до маразма =)

хотя bsd еще хуже... вот Майкрософтовцы и оперовцы делают все не just for fun, а как работу - и у них лучше получается чем у любых gpl'ников...

Re:

Ну да щазз...

Когда опера начнет нормально показывать странички (в том числе, хит сезона - НЕпоказ gmail'а), тогда и будем разговаривать о "лучше, чем у любых GPL'ников". А пока фтопку.

Re:

> Но вот покажите мне обсуждение выбора "плюсов" компанией Толлтех? У меня лично впечатление, что это было сделано административно-командным путем...

Ну, а нам-то что от выбора троллей. К плюсам, особенно в тролльтековой интерпретации (_сознательно_ без темплейтов и всяких прочих вкусностей) вязаться немногим сложнее, чем к C. Привязки нынче, слава их создателям (и swig'у с sip'ом), появляются чуть ли не каждый день. Разве что, для моего любимого нынче языка программирования whitespace пока еще нет :-)

> что qt лидирует по привязкам?

freshmeat.net? Во всяком случае, для "major"-ов уже точно есть. И, аналогично, к KDE. То есть, это, фактически, уже не конкурентное преимущество GTK/GNOME.

> Да, есть ли у kde программа централизованных релизов разных bindings, как у гнома?

Вероятно, нет. Правда, стоит заметить, что в эту GTK/GNOME программу давеча не вписались вполне уважаемые pygtk и кто-то там еще. Да, я понимаю, что они просто сами тормозили, но это все равно несколько умаляет ценность данной программы для mere mortals.

> И я уж точно не буду комментировать отсутствие привязки к "главному языку униха" - об этом говорено-переговорено тут уже...

Rest in peace? ;-) В смысле, "главный язык униха"? ;-)

> ЗЫ Номер версии, кстати, никуда не адресует

Но вы-то откликнулись :-). Собственно, я этого и добивался ;-)

Темпы развития

>> Что не так с темпами развития?

Да нет, всё нормально. Я искренне верю, что гном года через 3-4 вполне догонит виндовоз. Года так 1990. :-))

>Да, есть ли у kde программа централизованных релизов разных bindings, как у гнома?

Административно-командный модуль имеет место быть - и называется kdebindings. Привязки к куче языков + скриптование из языка напрямую (вызвы DCOP), либо через бинарь dcop - замечтательно всё. Оно ж почти что основа технологии :-)

Когда начинали писать KDE 2.0 - IPC делали через mico - единственную вменяемую реализацию CORBA. Тормозило страшно, падало ещё страшнее. Решили делать свою lightweight систему - получился dcop. Гномовцам с orbit'ом больше повезло IMHO.

>открытость исходных кодов дошедшая до маразма =)

маразм - это как раз позволять другить делать бабки за свой счёт =)

>Да нет, всё нормально. Я искренне верю, что гном года через 3-4 вполне догонит виндовоз. Года так 1990. :-))

ню-ню. Виндовоз уже в глубокой заднице =)

> Ну, а нам-то что от выбора троллей.

Как это "вам-то что"? Если Вы захотите вписать еще одну билиботечку в kdelibs - Вы обречены пользоваться плюсами... И если кто-то брыкливый задаст себе вопрос "а фигля плюсы" - его расследование закончится очень быстро, перед закрытыми дверями фирмы Троллтех.

> фактически, уже не конкурентное преимущество GTK/GNOME.

А-а. Вы про это. Да, наверное, уже не преимушество. Но пока что все-таки говорить о _преимуществе_ Qt рановато. Кстати, между нами, переходя на личности конкретных bindings - Qt# как-то очень вяло тянется - последний релиз был ажно в марте - при том, какой интерес ко всякой диезовости сейчас испытывают разные толстые околинуховые кошельки...

> давеча не вписались вполне уважаемые pygtk и кто-то там еще

Выправятся, куды денутся. Просто у них one of those days:)

> Rest in peace? ;-) В смысле, "главный язык униха"? ;-)

Да-да. Именно тот, о котором Вы подумали:) Правда, не понял, кто именно Rest in Peace...

> Но вы-то откликнулись :-).

А-а, так это была банальная провокация?:) Ну, среагировал-то я явно не на фразу про номер версии...