Вторая ссылка в гугле
http://www.shlomifish.org/open-source/anti/autohell/

Ещё про libtool (лично сталкивался с её проблемами)
http://www.mail-archive.com/wget@sunsite.dk/msg07860.html

> Вторая ссылка в гугле http://www.shlomifish.org/open-source/anti/autohell/

Я читал (я вообще умею пользоваться гуглом, честно-честно). Но там упор делается на скорость (что меня интересует мало - конфигурация выполняется один раз), и вендосовместимость (не интересует вообще).

Тут: http://lucidfox.org/posts/view/556 тоже неубедительно - даже скорость не педалируется.

Я как раз сравниваю CMake и autoconf (без libtool и прочего мусора), и autoconf мне пока что нравится больше. Насколько я понимаю, CMake - интерпретатор уродливого недоязыка, который умеет генерировать Makefile'ы? Он чем-то принципиально отличается от того же SCons?

Ещё про libtool (лично сталкивался с её проблемами)

libtool да, ужасен, но и не нужен.

автолулзы!

1. CMake осваивается на два порядка легче, чем autotools. Ты можешь похвастаться _полным_ пониманием того, как autotools работают?
2. У autotools проблемы с upward/backward совместимостью. То есть может получиться так, что твоя программа для конфигурения будет нуждаться в строго определенной версии autotools. Не слишком-то удобно.
3. В отличие от autotools, сенерированные с помощью CMake makefiles умеют делать параллельную компиляцию си-шников из разных директорий. То есть эффективность make -jN возрастает.

Полагаю надежды на buildj

Autotools - глобально и надёжно. Существующие проблемы широко известны, воркэраунды в интернетах находятся. В качестве плюшек: мощная документация, море примеров (проектов), почти все существующие библиотеки легко цепляются (pkgconfig, все дела).

Верь мне, мне верить можно!

Верь мне, мне верить можно!

-- М-м-м!.. Так, может быть, вы, святой отец, ещё и CVSом пользуетесь?

смаке

у CMake при компиляции проекта показывается красивый разноцветный трейс с процентиками. это же весомейшее преимущество!

а то и VSS :-)

>что меня интересует мало - конфигурация выполняется один раз

так бывает не всегда. и да, скорость аутохелла просто ужасна.

Алсо, гентушники рассказывают про необхожимость держать зоопарк версий аутохелла для сборки

>у CMake при компиляции проекта показывается красивый разноцветный трейс с процентиками.

А если серьезно, cmake не генит такой ужасной выдачи. В режиме с подробностями легко разобрать вызовы компилятора с ключами

>В отличие от autotools, сенерированные с помощью CMake makefiles умеют делать параллельную компиляцию си-шников из разных директорий

хм, не знал. Точнее, для cmake всегда этим пользовался, но думал, что make -j N всегда работает

да. помню, было время, когда я сидел под FreeBSD, и у меня было много ненужного времени, чтобы смотреть на то, как собираются кеды из портов. и стоило лишь ненадолго запустить дерево пакетов на произвол судьбы, как в нём сразу появлялось штук 5 разных версий автолулзов.

Алсо, гентушники рассказывают про необхожимость держать зоопарк версий аутохелла для сборки

Это если они патчат файлы проекта. Для чистой сборки этого, естественно, не нужно. Впрочем, бывает, что приходится патчить и перегенерировать configure. И вот тут зачастую действительно начинается Жопа :(

>pkgconfig

его даже qmake цепляет, cmake и подавно

PS: Кто плотно пользовался автотулзами тот в цирке не смеется.

>перегенерировать configure

а для vcs-версий всегда нужно генерировать configure

а для vcs-версий всегда нужно генерировать configure

Это само-собой. Но это, скорее, или человек в деле => процесс с версиями скорее налажен или же ищет на свою розовую попку жестких приключений, тягая каренты из CVS. Но тут уж ССЗБ как говорится. Ибо отследить пути всех тараканов всей этой опсорсной пиздобратии и кто какой ногой какое ухо чешит и чем пользуется не под силу даже pkgsrc-никам.

 — М-м-м!.. Так, может быть, вы, святой отец, ещё и CVSом пользуетесь?

Да, приходится. На работе и для кое-каких проектов, в которые контрибьючу.

кеды-то, разумеется, я застал уже на CMake. а вот множество других пакетов было завязано на конкретные версии Autotools. зоопарк, в общем.

PS: Кто плотно пользовался автотулзами тот в цирке не смеется.

Я им пять лет пользуюсь, сохраняя и преумножая при это искромётное чувство юмора. Это помимо скромности.

> его даже qmake цепляет, cmake и подавно

cmake

А как? Просто я так понял что недостаточно чтобы в /usr/lib/pkgconfig лежал нужный pc файл, чтобы cmake мог им пользоваться. И как потом под оффтоп?

Ну к примеру мне надо на винде и на linux использовать из коробки libxml2 и libpng.

А как вы потом под оффтоп компилите (если компилите)? Дело в том что MSYS или старый с автоматическим инсталлером или новый ручками, так? Это мне не подходит.

У кого что болит, тот про то и говорит. Я просто занимаюсь разработкой на Linux, но потом нужна еще Windows сборка. Сам прописываю 100500 путей в compiler и linker в codeblocks под виндой. Хотелось бы решить проблему как-то. cmake не очаровал, autotools требуют уродский MSYS

У кого что болит, тот про то и говорит. Я просто занимаюсь разработкой на Linux, но потом нужна еще Windows сборка. Сам прописываю 100500 путей в compiler и linker в codeblocks под виндой. Хотелось бы решить проблему как-то. cmake не очаровал, autotools требуют уродский MSYS

Посмотри на boost или на ACE/TAO с их MPC. Оба прекрасно живут и собираются в обоих системах причем в каждой из них своим, нативным, компилятором.

Под оффтоп тупо заполняешь две переменные: путь к инклудам, путь к либе. Ну или что мешает в винде юзать pkgconfig? Главное все зависимости ставить в C:\local\ а цепляется просто

find_package( PkgConfig )

if( PKG_CONFIG_FOUND ) pkg_check_modules( PURPLE purple>=2.6.0 ) include_directories( ${PURPLE_INCLUDE_DIRS} ) else( PKG_CONFIG_FOUND ) set( PURPLE_INCLUDE_DIR «» CACHE PATH «Path to libpurple include dir» ) set( PURPLE_LIBRARY «» CACHE FILEPATH «Filepath to libpurple library» ) set( GLIB_INCLUDE_DIR «» CACHE PATH «Path to glib-2.0 include dir» ) set( GLIBCONFIG_INCLUDE_DIR «» CACHE PATH «Path to glibconfig.h file for glib-2.0» ) set( GLIB_LIBRARY «» CACHE FILEPATH «Filepath to glib-2.0 library» ) include_directories( ${PURPLE_INCLUDE_DIR} ${GLIB_INCLUDE_DIR} ${GLIBCONFIG_INCLUDE_DIR} ) list( APPEND PURPLE_LIBRARIES ${PURPLE_LIBRARY} ${GLIB_LIBRARY} ) endif( PKG_CONFIG_FOUND)

Как посмотрел, то это не прекрасно... Профит не заметен. Я говорю вот о чем.

vertexua@vertexua-laptop:~$ pkg-config --cflags gtkmm-2.4 cairomm-1.0 glibmm-2.4

-D_REENTRANT -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/giomm-2.4 -I/usr/lib/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include -I/usr/include/gtk-2.0 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/atkmm-1.6 -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/и доlib/sigc++-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0

Сборка в винде сводится к описанию этих путей _вручную_. Я запросил флаги от трех библиотек. Итог - 100500 путей, потому что там есть и sigc++ и pangomm. Тут они автоматически добавляются как зависимости.

Что толку будет «использовать Cmake, предварительно все равно описав все PATH». Поверьте, я и так их добросовестно описываю и это мне не нравится. Хотелось бы решения как cygwin с встроенным package manager, но для нативного windows приложения.

Я просто концентрируюсь на винде, потому что на linux вопрос ясен, что cmake, что autotools легко удовлетворяют потребности.

Вы говорите о них как о примерах сборочных файлов cmake? Я так понял?

Я просто видел много примеров, они были не менее запутанные чем autotools

>1. CMake осваивается на два порядка легче, чем autotools.

А если ты уже знаешь shell?

> А если ты уже знаешь shell?

.. то тебе еще нужно подучить m4 и разобраться в (невнятно) генераторах генераторов shell-скриптов.

Вы говорите о них как о примерах сборочных файлов cmake? Я так понял? Я просто видел много примеров, они были не менее запутанные чем autotools

Бустовую сборку я особо не ковырял. AFAIR там используется jam или в этом духе. А вот MPC - это надуровень. На входе - описание проекта, на выходе - gnu/borland make, проект MVC, скрипты autohell ещё чего то уже не помню весь список.

Т.е. в результате можно описать проект на MPC, запустить генерацию autoconf-а и он слабает все autoconf/make файлы. Которые в последствии можно отдать собственно честному autoreconf-у и он уже все нагенерит. А можно из того же проекта нагенерить обычные make файлы под gnu/borland/ms make. Или же нагенерить проекты для MSVC. В общем, достаточно удобная штука. Но.. Со своими спесфиськими странностями :) Опять же, это примерно как qmake - ну кто его использует за пределами Qt как выделенный продукт? Почти что никто. Так что если у вас используется ACE - MPC в зубы и вперед. Впрочем, он оттуда легко выделяется в отдельный модуль. Это по сути всего лишь толстый перловый скрипт.

>.. то тебе еще нужно подучить m4 и разобраться в (невнятно) генераторах генераторов shell-скриптов.

m4 такой же «сложный», как gcc -E

> m4 такой же «сложный», как gcc -E

autotools рядом с cmake не кажутся ни простыми, ни прозрачными

Именно. Хотелось бы что-то на подобии qmake, только для любых библиотек. Думаю что это сложно, потому что qmake привязан к Qt и знает только его флаги. Под оффтопом он не решает проблему с libpng к примеру. И откуда ему знать где оно лежит?

Нужно общее дерево либ. MSYS+pkgconfig могло бы быть решением, но к несчастью оно в жалком состоянии

> Верь мне, мне верить можно!

Хотя ты толстый лиспотролль же, убеждать ты умеешь :)

Именно. Хотелось бы что-то на подобии qmake, только для любых библиотек. Думаю что это сложно, потому что qmake привязан к Qt и знает только его флаги. Под оффтопом он не решает проблему с libpng к примеру. И откуда ему знать где оно лежит?

pkg-config

Нужно общее дерево либ. MSYS+pkgconfig могло бы быть решением, но к несчастью оно в жалком состоянии

Я конечно не пользовался pkg-config на винде, но разве его нельзя там собрать нативно без всяких больных на всю голову msys?

http://pkg-config.freedesktop.org/wiki/

pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly.)

Утверждают что можно. Впрочем, может и врут. Я не проверял.

> 1. CMake осваивается на два порядка легче, чем autotools. Ты можешь похвастаться _полным_ пониманием того, как autotools работают?

Да я ни о том, ни о другом пока что ничего не знаю. Но больно уж ублюдочный скриптовый язык у CMake.

2. У autotools проблемы с upward/backward совместимостью. То есть может получиться так, что твоя программа для конфигурения будет нуждаться в строго определенной версии autotools.

Ы конкретно моем случае это не проблема. У меня вообще узкая и специфическая задача - прописать в makefile'ы пути, обнаружить несколько библиотек и проверить наличие кросс-компилятора. libtool и вся мощь automake мне не нужны.

Ну я не утверждал что нельзя. ) А где потом брать .pc файлы с путями C:\mylibs\libpng? Самому писать? Вот и вернулись в начальную позицию

>А как? Просто я так понял что недостаточно чтобы в /usr/lib/pkgconfig лежал нужный pc файл

cmake --help-module FindPkgConfig

И как потом под оффтоп?

а с оффтопом всегда проблемы. кросс-компиляция даже иногда проще выходит) знаю, что есть порт pkg-config на оффтоп, но с деталями не знаком

/me робко предлагает qmake. Простой язык, при надобности допускающий довольно сложные конструкции, поддержка .pc, кросс-компиляция с Qt работает без ацких бубнов (в отличие от cmake:), автогенерация проектных файлов наконец.

> Да я ни о том, ни о другом пока что ничего не знаю. Но больно уж ублюдочный скриптовый язык у CMake.

Мне, напротив, пришлось жить как с тем, так и с другим. Учитывая, что деньги платят за работающий код, а не за фапанье вприпрыжку вокруг системы сборки, времени на вникание всегда было мало. Так вот, чтобы на ровном месте изобрести что-то запутаннее этого высера на m4, надо хорошенько постараться. http://upload.wikimedia.org/wikipedia/commons/8/86/Autoconf.svg

> pkgconfig, все дела

если в autoconf цепляется все легко, то тогда в cmake вообще тривиально

> Qt работает без ацких бубнов (в отличие от cmake:),

cmake поддерживает Qt из коробки, бубнов никаких нет

А завтра тебе понадобится кроссплатформенность или еще что и со своим autocrap'ом ты сядешь в лужу. Может лучше сразу привыкать к хорошим вещам?

> А завтра тебе понадобится кроссплатформенность

Не понадобится (да, точно).

Может лучше сразу привыкать к хорошим вещам?

«Хорошая вещь» - это CMake? Если да, то правильно ли я понимаю; это нечто вроде SCons/waf (т.е. система сборки, основанная на скриптовом языке, в отличие от make, который декларативен)? Потому что встроенный язык CMake мне сильно не нравится (впрочем, m4 в autoconf тоже не фонтан).

А завтра тебе понадобится кроссплатформенность или еще что и со своим autocrap'ом ты сядешь в лужу.

Почему?

Неправильно, у cmake декларативный синтаксис.

это ты спроси у разработчиков autocrap'а почему они написали такое некроссплатформенное гуано в котором без принятия веществ не разберешься

это ты спроси у разработчиков autocrap'а почему они написали такое некроссплатформенное гуано в котором без принятия веществ не разберешься

По существу вопроса: какие проблемы у autoconf&co с кроссплатформенностью, и как проекты, их использующие, собираются на линуксе, бзд, вендах и пачке проприетарных юниксов?

> собираются на линуксе, бзд, вендах и пачке проприетарных юниксов?

В линухе более-менее нормально, а в других системах собираются с огромными проблемами с необходимостью установки гнутого г-на и прочих цигвинов. Нативные средства autocrap не использует.