Autohell

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

Ну ХЗ. Как по мне, так это чистое скриптование:

IF(NOT EXISTS "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt")
  MESSAGE(FATAL_ERROR "Cannot find install manifest: \"@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt\"")
ENDIF(NOT EXISTS "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt")

FILE(READ "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt" files)
STRING(REGEX REPLACE "\n" ";" files "${files}")
FOREACH(file ${files})
  MESSAGE(STATUS "Uninstalling \"$ENV{DESTDIR}${file}\"")
  IF(EXISTS "$ENV{DESTDIR}${file}")
    EXEC_PROGRAM(
      "@CMAKE_COMMAND@" ARGS "-E remove \"$ENV{DESTDIR}${file}\""
      OUTPUT_VARIABLE rm_out
      RETURN_VALUE rm_retval
      )
    IF(NOT "${rm_retval}" STREQUAL 0)
      MESSAGE(FATAL_ERROR "Problem when removing \"$ENV{DESTDIR}${file}\"")
    ENDIF(NOT "${rm_retval}" STREQUAL 0)
  ELSE(EXISTS "$ENV{DESTDIR}${file}")
    MESSAGE(STATUS "File \"$ENV{DESTDIR}${file}\" does not exist.")
  ENDIF(EXISTS "$ENV{DESTDIR}${file}")
ENDFOREACH(file)

Недекларативные конструкции поддерживаются, куда же без них. Но обычно это всё запрятано глубоко и в большинстве случаев такие сложности писать не приходится. Из «скриптования» максимум используется if для определения типа платформы.

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

Почему GNU Autotools должны использовать левый и, вероятно, проприетарный софт? Я не вижу причин, почему автотулзы должны нативную хрень поддерживать.

Ну тогда о какой кроссплатформенности может идти речь? И почему у cmake нет с этим проблем?

Ну тогда о какой кроссплатформенности может идти речь?

Ты не ответил на вопрос: почему кроссплатформенный софт, использующий автотузл (и прочий софт из гнушного тулчейна), кроссплатформенный?

И почему у cmake нет с этим проблем?

Дешёвая размалёванная проститутка, умеющая пару распространённых поз. А вот когда нужно настоящее искусство камасутры применять (собирать на редких платформах), там без autotools никуда.

> Ты не ответил на вопрос: почему кроссплатформенный софт, использующий автотузл (и прочий софт из гнушного тулчейна), кроссплатформенный?

Софт (но не сам autocrap!) кроссплатформенный не благодаря autocrap'у, а вопреки ему. Для винды кстати такие проекты обычно держат отдельные файлы проектов, тем самым выполняя двойную работу.

собирать на редких платформах

Вначале пусть он научится работать на распространенных платформах.

>cmake поддерживает Qt из коробки

кросс-коспиляцию? рассказывай сказки

Насчет кросс-компиляции именно Qt не знаю, не заморачивался этим вопросом. А вообще cmake поддерживает кросскомпиляцию, на работе использую как раз cmake для сборки arm-кода.

>А вообще cmake поддерживает кросскомпиляцию

это понятно, задаешь CC, CXX какие надо и все. А с кутами проблема - их расположение выясняется FindQt4 с помощью qmake, поэтому кросс-компиляция на линухе под вынь возможна только через одно место. Да? можно задать пути ко всем либам руками, но FindQt4 отвечает и за обработку локализаций, вызов moc, uic...

Дешёвая размалёванная проститутка, умеющая пару распространённых поз. А вот когда нужно настоящее искусство камасутры применять (собирать на редких платформах), там без autotools никуда.

Ну да ну да. Без грамотно и хорошо написанных сценариев к автотулзам я бы сказал так. Что бывает ой как далеко не всегда.

>собирать на редких платформах

не позорьтесь, cmake поддерживает огромное количество платформ и компиляторов

угу, автохрень поддерживает только одну платформу — GNU/подставьте_ваше_ядро

Как сделать один простенький CMakeLists.txt, чтобы он сразу подхватил libpng, gnutls, libxml2 на Linux, BSD и Windows. Причем если я устанавливаю все либы на винде в одно дерево, так же как и на Linux, то где, к примеру, в инсталлере с libxml2 лежит файл специально для cmake, который подключит libxml2 только по факту указания пути к дереву, ведь внутри дерева свой стандартный путь?

 
vertexua@vertexua-laptop:~$ pkg-config --cflags libxml-2.0 
-I/usr/include/libxml2 

Как в винде это заменить на -IC:\mylibs\include\libxml2

Тоесть на линуксе я хочу чтобы все собралось сразу, а на Windows я через ключ написал что-то типа cmake --path-to-root=c:\mylibs

Пока этого не будет - ВСЕ системы сборки ниразу некроссплатформенное говно.

Ближе всех к нормальному qmake, но он не в тему, так как только Qt находит из коробки. Шаг влево, шаг вправо - расстрел

У цмака есть куча проблем с кросскомпиляцией. Я вот просто не в состоянии никаким образом собрать под Symbian собрать Qtшный проект им. Видимо придется qmakeовский проект делать... А так бы уже сейчас тестил Кутим на Симбиане

>Ближе всех к нормальному qmake, но он не в тему, так как только Qt находит из коробки.

QMake расширяем - можно писать .prf файлы, позволяющие подключать *любые* либы простым CONFIG += libpng libxml2 etc.

Другое дело - я понятия не имею, делал ли их уже кто-нибудь.

>Тоесть на линуксе я хочу чтобы все собралось сразу, а на Windows я через ключ написал что-то типа cmake --path-to-root=c:\mylibs

Так просто с cmake не выйдет, придется через -D задавать инклуды и либы. Например, openbabel я собрал без труда (правда, делал кросс-компиляцию)

Кросскомпиляция - другое дело. Тут есть shell и этим все сказано. Как вы видите, то меня и autotools устраивает, но все упирается в MSYS

>Тут есть shell

Единственное, что здесь упрощает шелл - набор путей табами) на офтопике можно натыкать библиотек мышкой

Единственное что для меня упрощает шелл - возможность запуска autotools. Ну есть у вас autotools, как его запустить без shell под оффтоп?

я-то про cmake говорил, который и без шелла работает. автолулз конечно не запустится. РМС придумал-таки свой зонд против оффтопика)

Господа, а кто-нибудь смотрел на mk-configure?

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

> Насколько я понимаю, CMake - интерпретатор уродливого недоязыка, который умеет генерировать Makefile'ы? Он чем-то принципиально отличается от того же SCons?

конечно, отличается. SCons — это продолжение идеи Jam/Maven, но с языком общего назначения. Make-файлы — декларативные, но черезчур детальные и подробные до дебилизма. В итоге, никто не хочет писать makefile руками — нудное это занятие, да и сделать ручками нормальные цели make dist / make doc / make test как в autotools — занятие для терпеливых ^W зануд. GNU make пытается выкрутиться с VPATH и прочими расширениями, чтобы описание стало более шаблонным. BSD make вместо этого пытается инклудить стандартный набор правил. Но работает эта вся машинерия autotools+make+ сгенерированные makefile не быстро, почему — см. «Recursive make considered harmful». На POSIX мы ещё имеем быстрый fork, а на других системах с тяжёлым CreateProcess можно вешаться.

Поэтому тот же Jam уже более «правильная вещь». Во-первых, один запуск процесса на все «рекурсивные Jamfile», во-вторых, имеем вместо детальных императивных/некоторых неявных инструкций набор правил, системно, компиляторо, проектозависимых. Пишем свои правила как плагины. Интерпретатор однопроходный, опять же. Другое дело, что интерпретатор сам по себе не очень быстрый.

В итоге имеем 2 основных подхода — make и jam/boost.build, ant и maven, условно говоря «императивный и на базе правил». Другое дело, что изучать свой язык на каждый чих — лень. Поэтому тот же SCons, Waf — расширяются проще, потому что «плагины» пишутся на обычном питоне. Правда, с декларативностью становится хуже.

В SCons особое внимание уделено воспроизводимости билдов. Новые цели запускаются по изменившимся сигнатурам от содержимого, а CMake — просто очередной генератор Makefile вроде autotools (то есть, в случае распределённой сборки/неточности с временем билды могут быть «неаккуратные»). В итоге, SCons может собирать проект и медленее, чем хорошо написаный Jam/хорошо написаный Makefile/рекурсивные сгенерированные Makefile, но он гарантирует воспроизводимость билдов, что всегда будет собираться именно такой конкретный бинарник. А у Make — могут быть неаккуратные пересборки.

С точки зрения поддержки жизненного цикла, у Maven/SCons/Waf/Jam ситуация получше, чем у Ant/Make/Mk — можно добавить свой плагин очень просто, например, получить continuous integration систему. Проще с распределённой сборкой. Проще с репозиториями кода вроде maven/nexus или аналога distcc в SCons.

с другой стороны, в CMake тоже есть CTest, в autotools make dist/make doc/... — и запускается он через сгенерированные обёртки в Makefile, то есть, копирует все недостатки make (неаккуратные сборки). Если вручную запускать, нет особой разницы. Если ЖЦ с процессами — тады ой.

Ant/Make — примитивный по возможностям и лучше/хуже расширяемый, поэтому и возникает необходимость в обёртках и «генераторах Makefile». В том же SCons/Waf/Maven/Jam для этого просто пишется плагин.

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

гуглим книжку с картинками, смотрим на gnu.org и в ту же википедию. Видим — генерируется дофига промежуточных файлов для имитации поддержки нужного жизненного цикла процесса разработки/поддержки. Видим — вариант билды «из коробки», mkdir build1;cd build 1; ../configure .... Видим — можно потестировать кросссборки запуском вроде make CC=кросскомпилятор DESTDIR=туда install , понимаем — полезная штука для дистростроителя/тестировщика, поставить куда-то в tmp или в /mnt/arm/root и погонять. Видим — зависимостей от тулчейна минимум, для ./configure && make && make install нужен только POSIX shell и cc.

правда, нафига нам всё это в зоопарке ^U для обычной, не кросс разработки?

> море примеров (проектов)

а потом из-за бездумного копирования непонятной мутоты возникает культ карго в программировании http://www.airs.com/blog/archives/294

«не знаю, как эта хрень работает, содрано с примера»

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

у Waf он тоже показывается, низачод.

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

перед чтением мануала аутотулз рекомендуется осилить «Процесс» Ф.Кафка, «Замок Горменгаст» Мервин Пик, «Приглашение на казнь» В. Набоков, Beowulf и старшие Эды.

Аутотулзы тебе покажутся раем после этого, я гарантирую это!111

>А как вы потом под оффтоп компилите (если компилите)?

как-как, как обычно. Гентой под винду и собираю, Mingw-ом, ага. Ставим crossdev, собираем кросс mingw, обертками над emerge вроде i686-pc-mingw32-emerge (симлинк на cross-emerge враппер над emerge) собираем пакетики.

Палудисом тоже можно, даже проще чем емёрджем. Пакетики, естественно, портированы должны быть или POSIX-подобны.

Mingw/MSYS/Cygwin под винду — это вообще недоразумение какое-то. Во-первых, в винде нету форка, и оно валится с ошибкой 0 «Сygwin heap error». Перезапускаем заново — компиляет дальше, занавес. Линуксовый кросс-мингв как-то стабильнее работает, всё-таки.

> Сам прописываю 100500 путей в compiler и linker в codeblocks под виндой. Хотелось бы решить проблему как-то

осиль уже правильно прописанный CHOST, CTARGET и ROOT. Врапперы над емерджем это и делают — настраивают CTARGET на кросс мингв и ROOT на образ целевой винды. А потом собирают обычным emerge, то есть, обычным configure/make/make install (который запускает кросс мингв и кросс бинутилзы из линукса в винду, есессно )

внезапно, CMake умеет генерировать makefile для студиозусова nmake. Boost, как всегда, выбирает велосипед ^W jam ^W boost.build

>Что толку будет «использовать Cmake, предварительно все равно описав все PATH». Поверьте, я и так их добросовестно описываю и это мне не нравится.

ты не поверишь. Загляни в профиль нормального пакетного менеджера, и посмотри, как он там описывает все пути/инклуды/либы/кросстулчейн

Хотелось бы решения как cygwin с встроенным package manager, но для нативного windows приложения.

читай гентушный embedded howto, crosscompiler howto, crossdev, crossdev-wrapper Поставь кросстулчейном mingw и посмотри на ROOT установленного нового профиля — он в процессе сборки делает оверлей с кросстулзами, новый профиль для пакетного менеджера (обёртки над emerge-ом), правильные переменные в профиле.

Наверное, в арче с его pacman-ом даже попроще будет, ибо пакетный менеджер на шелле. Но не принципиально — главное, что правильно прописанный ROOT/CHOST/CTARGET сделает тебе половину работы.

Естественно, ты не сможешь так собрать абсолютно любой пакет, кросс обёртками. Портировать надо по-нормальному. Для начала собери кросс обёртками app-misc/hello — GNU hello world, runtime зависимостей у него минимум и портировать не надо вообще ничего.

C real world apps вроде qt-шных, gtk-шных — надо портировать сам qt и gtk, и оформить их в виде пакета в оверлее рядышком с cross-i686-pc-mingw/{gcc,binutils,win32api}.

Поэтому лучше брать не emerge, а paludis — в палудисе есть importare, а в портадже инъектированные пакеты выпилили.

Алсо, nix пакетный менеджер тоже годный для этого.

> AFAIR там используется jam или в этом духе

да, boost.build — это форк jam , но какой-то больной на голову. См. сравнение make vs. ant vs. scons vs. jam vs ...  — boost.build по всем параметрам уступает исходному jam, не понятно, зачем он вообще такой нужен.

ещё из генераторов cook и bakefile простые и понятные.

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

ни разу это не решение, костыль какой-то. Сравни .bashrc в MSYS и профиль нормального пакетного менеджера, вот где толстота-то.

под «больным на голову msys»-ом всё работает, я гарантирую это.

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

то есть, всё то, что по дефолту отрабатывает само в правилах по умолчанию в обычном jam-е. Добавь переменных в Makefile, заполняемых из config.h/configure

а где по-твоему, msys и его pkgconfig ищут дефолтные .pc? в $HOME, в c:/usr/local, и т.п. C:\mylibs\libpng => /c/mylibs/libpng, но нормально установленный мсис должен сделать домашний каталог пользователю и складывать туда всю свою требуху. Или под c:\mingw\usr\local, c:\msys\usr\local поискать.

make декларативен, но слишком примитивный. Поэтому приходится писать много элементарных императивных действий поверх декларативной «обёртки». SCons/Waf/Maven — императивен by design, плагины на самом питоне/яве/whatever. Jam — декларативен, но высокоуровневый, понимает правила и позволяет писать новые на своём языке правил.

да наверное, потому же, что и GNU hello world, тоже вещества пачками. Вся эта ботва когда-то была нужна, запускать ручками по фиче за раз, но когда, кому и зачем — уже даже и старожилы не помнют.

фортран, да? :)

дело не в том, поддерживают/не поддерживают вообще, а как именно поддерживают. Autotools подразумевает POSIX shell, gcc в виде разных процессов фронтенда/бекенда, мейк/форк/куски на скриптах — это всё неявно подразумевает POSIX, perl, awk, m4 и дешёвый fork. Передачу настроек через переменные окружения сюда же.

«Вы можете купить форд любого цвета, если этот цвет — ч0рный» vs. «вы можете вступать и кросскомпелировать в любую систему, если эта система — POSIX»

> почему кроссплатформенный софт, использующий автотузл (и прочий софт из гнушного тулчейна), ТАКОЙ кроссплатформенный?

не аргумент. Вот Ant/Maven и asdf/defsystem тоже ТАКИЕ себе кроссплатформенные, а толстота-то — разная!!!111...

осиль side-by-side install. Намёк, FindQt запускается базовый или целевой и откуда имено?

> make декларативен, но слишком примитивный. Поэтому приходится писать много элементарных императивных действий поверх декларативной «обёртки».

А мне нравится GNU Make, его все знают (ну, более-менее), и у меня довольно много makefile'ов для всякого нестандартного хлама. Насколько я понимаю, для того же CMake придется их переписывать, и учить убогий внутренний язык CMake, причем учить не только мне, а всем участникам проекта. Это при том, что всего-то надо проверить систему на наличие библиотек, компиляторов, и прописать пути к ним в makefile'ы (желательно, подключаемые по include). Automake, libtool и всё прочее in all its glory просто ненужно.

Против Jam те же возражения, что и против CMake, против SCons/waf - мне вообще не нравится идея сборки скриптом (пришлось как-то разбираться в нескольких SConstruct - муть неудобная).

фортран, да? :)

Епт, а ведь правда похоже. Хотя скорее - странный ублюдок Фортрана и Фокспро %)

> Ну есть у вас autotools, как его запустить без shell под оффтоп?

без баша? никак. Может, варианты pdksh/шелл из dmd подойдут, но без нормального баша без ограничений на размер окружения и форка — никак.

>без баша? никак.

автолулзу баш не нужен. Ему подойдет любая POSIX-совместимая оболчка, даже ksh, идущий с Windows SFU

> вы можете вступать и кросскомпелировать в любую систему, если эта система — GNU

fixed

autocrap активно использует гнутые тулзы и гнутые расширения, поэтому posix'ом тут и не пахнет

>side-by-side install

с этого места по-подробнее

FindQt

конечно, хостовый) не ставить же мне cmake в wine ради этого

>autocrap активно использует гнутые тулзы

на фряхе он вроде и без баша нормально работает

Если делать правильный makefile, который корректно отрабатывается ВСЕ зависимости, корректно находит ВСЕ нужные библиотеки, то в результате получится такая лапша, что приведенный фрагмент скрипта на cmake покажется детским лепетом.

Еще раз повторюсь — именно скрипты на cmake писать приходится очень редко, потому что в стандартном комплекте есть скрипты практически на все случаи жизни.

зато с гнутым окружением, без него не взлетает