LINUX.ORG.RU

как избавиться от libtool не избавляясь от automake?

 , ,


5

5

всем привет.

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

теперь, собственно, описание проблемы.

есть automake, есть много Makefile.am, в которых делается что-то вроде такого:

pkglib_LTLIBRARIES = mylibrary.la
mylibrary_la_SOURCES = mylibrary.c
mylibrary_la_LDFLAGS = -module

соответственно, для таких модулей будет использоваться libtool, который

  • сгенерирует огромную кучу всяких файлов, типа .la, .lo, .lai, .Plo
  • при сборке будет автоматически использоваться libtool при подключении чужих библиотек, используя .la файлы в /usr/lib например
  • помимо mylibrary.so, будут сгенерированы mylibrary.so.0.0.0 и mylibrary.so.0, и засимлинканы друг на друга
  • при попытке кросскомпилить, или использовать не-системные версии библиотек при сборке, libtool ведет себя совершенно непредсказуемо, выдает бредовые ошибки, использует не те библиотеки которые ему сказано, и вообще говно.
  • .la файлы будут включены в install target, и создадут бесполезный мусор в /usr/lib
  • сборка статического билда очень усложняется, т.к. неизвестно, увидел ли libtool именно нужную библиотеку, или слинковался с системной (а это он умеет)
  • к библиотекам неявно прилинковывается всякий шлак, который добавляется по типу исходника — например, при сборке .cpp файлов автоматом к линку добавляется всякий libstdc++ и libgcc_s, даже если он не нужен, т.е. в скрипте libtool (некоторых версиях) можно увидеть добавление вот таких аргументов к командной строке "-lstdc++ -lm -lgcc_s -lc -lgcc_s", gcc_s 2 раза видимо для надежности.

короче, предполагается, что целевая аудитория данного треда в курсе о чем речь :)

ну и собсно, финальный вопрос. есть ли в природе какие-то альтернативные automake macros, чтобы вообще совсем навсегда избавиться от libtool?

что от макроса(-ов) требуется:

  • компилить .so, как с префиксом «lib», так и без него, т.е. как в libtool с -module
  • чтобы указание -lname линковало только libname.so из -L (с соблюдением стандартного search order), и всегда игнорировало .la файлы в $LIBDIR
  • чтобы никаких la файлов и versioned so не создавалось (опциональная возможность versioning приветствуется)
  • чтобы сборка работала на linux/win/osx/bsd (через gcc/llvmgcc)

понимаю, что вменяемого способа решить эту проблему может и не быть, поэтому предложения полной смены билд системы тоже приветствуются. но альтернативная система не должна требовать установки ничего кроме make+coreutils у юзера, и должна быть не хуже autotools по фичам — т.е. уметь make distcheck, make install/uninstall, использовать configure, и всякие подобные штуки (в связи с чем предлагателей cmake, опять же, попрошу не обращаться).

например, кто-то смотрел что используется в ffmpeg? там что-то свое, или у него есть сайт?

★★★★★

Ответ на: комментарий от Manhunt

Есть два широких класса разработчиков: те кто пытается ужиться с autocrap таким какой он есть, и те кто уже отказался от autocrap в пользу чего-нибудь более вменяемого.

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

Отличное требование к альтернативной системе сборки! А дрочить вприсядку не надо?

в чем проблема? есть же альтернативные системы, использующие configure. тот же ffmpeg как пример.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

в чем проблема? есть же альтернативные системы, использующие configure. тот же ffmpeg как пример.

блин, в ffmpeg configure - это просто шелл-скрипт, написанный руками. Его можно как угодно назвать.

anonymous
()
Ответ на: комментарий от anonymous

в ffmpeg configure - это просто шелл-скрипт, написанный руками.

А в чем профит от этого?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

блин, в ffmpeg configure - это просто шелл-скрипт, написанный руками. Его можно как угодно назвать.

ага, но он при этом намного лаконичнее и понятнее, чем любой виденный мной configure.ac. так что вариант шелл-скрипта с простым и понятным синтаксисом меня вполне устроил бы. гораздо важнее, чтобы libtool'а не было.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

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

Ок, по религиозным причинам cmake вычёркиваем. scons уже предложили — но и он тебе с почему-то не подошёл.

Серьезно, я не понимаю: сборочная система у тебя несет такие непростые программы как компилятор и make, но интерпретатор питона/cmake на ней внезапно оказывается табу. С какого бодуна?

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от Manhunt

Ок, по религиозным причинам cmake вычёркиваем. scons уже предложили — но и он тебе с почему-то не подошёл.

ответь сам себе на вопрос: scons или cmake могут делать все пункты, которые я перечислил? представим себе, что они установлены.

особенно важные вещи, чтобы ты ничего не упустил: сборка и валидация тарболла, поддержка install/uninstall, возможность сконфигурировать проект перед сборкой (включить/выключить фичи, генерация config.h, передача параметров конфигурации сборочным скриптам конкретных модулей, определение host/target архитектуры, с возможностью настроить проект под них), возможность подключать 3rd-party библиотеки, как через pkg-config, так и без него, в т.ч. если они установлены в другой префикс нежели компилируемый проект. желательна поддержка кросс-компиляции.

(это далеко не полный список того, что мне надо от сборочной системы, но примерное направление должно стать понятно)

waker ★★★★★
() автор топика
Последнее исправление: waker (всего исправлений: 2)
Ответ на: комментарий от waker

ответь сам себе на вопрос: scons или cmake могут делать все пункты, которые я перечислил? представим себе, что они установлены.

Отвечу про cmake, поскольку со скунсом знаком слишком поверхностно.

сборка и валидация тарболла

Да, директивой ADD_CUSTOM_COMMAND

поддержка install/uninstall

Есть в каком-то виде, на практике никогда не пользовался и потому деталей сказать не могу.

возможность сконфигурировать проект перед сборкой

Да, ключи командной строки в духе -DFEATURE_BLABLA=ON

генерация config.h

Да, из config.h.in директивой CONFIGURE_FILE

передача параметров конфигурации сборочным скриптам конкретных модулей

Смотря что имеется ввиду.

определение host/target архитектуры, с возможностью настроить проект под них

Не определение, а задание. Через toolchain-файл.

возможность подключать 3rd-party библиотеки, как через pkg-config, так и без него

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

если они установлены в другой префикс нежели компилируемый проект

Да.

желательна поддержка кросс-компиляции.

Да.

это далеко не полный список того, что мне надо от сборочной системы, но примерное направление должно стать понятно

Разумеется, это не полный списко того, что умеет cmake. Но статус в общих чертах обрисован :)

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Серьезно, я не понимаю: сборочная система у тебя несет такие непростые программы как компилятор и make, но интерпретатор питона/cmake на ней внезапно оказывается табу. С какого бодуна?

несмотря на то, что этот параметр не является основным критерием выбора сборочной системы вообще, я отвечу на этот вопрос.

сборочных систем дохрена — cmake, qmake, scons, jam, самописные шелл-скрипты с make, тот же mk-configure, тот же qbs, и множество других.

но первая вещь, которую узнает каждый начинающий линуксоид, собирая нужный софт из исходников — это магическая комбинация ./configure ; make ; make install; и наличие файла INSTALL.

эту комбинацию реализуют автотулсы.

все юзеры знают о ./configure --help, и всегда есть INSTALL с инструкцией.

когда я скачиваю проект использующий cmake - я сначала делаю ./configure --help. потом я обнаруживаю что ./configure нету. тогда я делаю less INSTALL — его тоже нету. тогда я делаю ls, и обнаруживаю что-то вроде projectname.txt, читаю, и там написано, что для установки надо сделать что-то вроде cd bin; cmake ..; make ; make install.

я выполняю cmake - и чаще всего обнаруживаю, что он не установлен. аналогичная ситуация со всеми остальными подобными поделками, типа qmake и scons.

там _никогда_ не написано, как поставить программу в другой префикс. как указать ей откуда брать зависимости. часто вообще никакой инструкции нет.

более того, cmake просто может быть не установлен. несмотря на то, что, по факту, для _сборки_ ничего кроме make не нужно, а make есть даже в POSIX, тут требуется какой-то непонятный cmake (или qmake, или scons) - и все они почему-то вместо стандартного ./configure ; make ; make install навязывают каждый свой синтаксис, который почему-то всегда намного хуже автотулсового.

вот по этим причинам, тулзы подобные cmake вызывают у меня неприятие.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

Кстати, cmake умеет и тестовые файлы компилить и запускать (я так делал для определения целевой архитектуры CUDA, чтобы компилять с оптимизациями под конкретную архитектуру).

Anon
()
Ответ на: комментарий от waker

я ни в зуб ногой по сборке софта на с/с++ но читал гдето что в qt пошли по следующей цепочке cmake -> qmake -> qbs

ZuBB ★★★★★
()
Ответ на: комментарий от Manhunt

Да, директивой ADD_CUSTOM_COMMAND

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

Смотря что имеется ввиду.

имеется ввиду

case "$host" in
  *-apple-*)
    OS="osx"
    ;;
  *)
    OS="unknown"
    ;;
esac
AC_SUBST(OS)

Не определение, а задание. Через toolchain-файл.

нет, нужно именно определение — подходящий пример выше.

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

ответь прямо, как мужик, прямые аналоги AC_CHECK_LIB и PKG_CHECK_MODULES есть?

соберется ли проект, если в cmakelist указана зависимость от liba.so, а она не установлена (но при этом для сборки опциональна)?

можно ли проверить наличие нескольких библиотек, делающих одно и то же, и выбрать из них то что больше подходит?

Разумеется, это не полный списко того, что умеет cmake. Но статус в общих чертах обрисован :)

ответы далеко не полные. наводят на мысль, что все придется колхозить.

waker ★★★★★
() автор топика
Последнее исправление: waker (всего исправлений: 1)

вобщем, как и ожидалось, набежали фанаты cmake.. значит кроме флуда ничего не будет. вроде обсудили все возможные варианты. пока, видимо, проще всего продолжать использовать libtool. тему отмечаю как решенную.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

Да, директивой ADD_CUSTOM_COMMAND

можно пример такой директивы?

можно

чтобы сгенерировался тарболл со всеми файлами, включенными в проект

Я обычно для этого делаю hg ar

скомпилировался, проинсталлировался, деинсталлировался, и по завершении выдался результат теста на корректность

cmake && make && make install && make uninstall (правда, с этим придется повозиться маленько)

прямые аналоги AC_CHECK_LIB и PKG_CHECK_MODULES есть?

find_package и pkg_check_modules

соберется ли проект, если в cmakelist указана зависимость от liba.so, а она не установлена (но при этом для сборки опциональна)?

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

можно ли проверить наличие нескольких библиотек, делающих одно и то же, и выбрать из них то что больше подходит?

Можно.

наводят на мысль, что все придется колхозить

Не обязательно: много удобных конструкций уже есть + в интернете дофига найти можно.

Anon
()
Ответ на: комментарий от Anon

соберется ли проект, если в cmakelist указана зависимость от liba.so, а она не установлена (но при этом для сборки опциональна)?

Не соберется.

Соберется. По факту неудачного поиска тебе выставят переменную LIB_NAME-NOTFOUND, так что остается только описать правильно поведение для обоих случаев: когда либа нашлась, и когда не нашлась.

Manhunt ★★★★★
()
Ответ на: комментарий от Anon

можно

я имел ввиду, конкретно пример как сделать make distcheck через add_custom_command.

Я обычно для этого делаю hg ar

[waker@lazer deadbeef]$ git archive --format=tar HEAD | bzip2 > archive.tar.bz2
[waker@lazer deadbeef]$ ls -l archive.tar.bz2 
-rw-rw-r-- 1 waker waker 6393786 Oct 22 19:19 archive.tar.bz2
[waker@lazer deadbeef]$ ls -l deadbeef-0.6.0-beta5.tar.bz2 
-rw-rw-r-- 1 waker waker 3592004 Oct 22 00:12 deadbeef-0.6.0-beta5.tar.bz2

предлагаешь раздавать юзерам 6 мегабайт вместо 3.5? (edit: сорри, тут показалось 64 мегабайта вместо 6 - исправил)

find_package и pkg_check_modules

по синтаксису в несколько раз больше букв писать, чем в autoconf. в чем профит?

Не соберется.

... но можно колхозить. понятно.

Не обязательно: много удобных конструкций уже есть + в интернете дофига найти можно.

удобные инструкции не аргумент против готовых работающих встроенных функций в autoconf.

waker ★★★★★
() автор топика
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от waker

все юзеры знают о ./configure --help, и всегда есть INSTALL с инструкцией.

Юзеры знают о пакетном менеджере. Если ты не выкатил им готовый rpm/deb/tgz пакет, то ты.. обошелся с ними некрасиво.

А сборка — для тех, кто знает, что делает. Она в любом случае требует довольно высокой квалификации, так что жаловаться на незнание команды cmake — это просто смешно. И ничто не мешает приложить файлик INSTALL с инструкцией.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Anon

Если укажешь, что данная библиотека обязательна, то фигвам.

Зачем? По условия задачи она была опциональна.

Manhunt ★★★★★
()
Ответ на: комментарий от waker

как сделать make distcheck через add_custom_command

А, звиняй. Я даже не знаю, что эта цель должна делать.

предлагаешь раздавать юзерам 64 мегабайта вместо 3.5?

А как у тебя получается, что архив репы больше архива нужных файлов?

по синтаксису в несколько раз больше букв писать, чем в autoconf. в чем профит?

В скорости.

понятно

Ну, дык это похоже на спор AVR'щиков с ARM'овцами ☺

Anon
()
Ответ на: комментарий от Manhunt

Я дальше и написал это. Читай внимательней. Я и сам в приведенном выше примере часть библиотек помечал как REQUIRED, а часть — не помечал и выставлял нужные флаги. Правда, там я ступил: если ни одной библиотеки вывода графики не будет найдено, получится небольшой бульбец.

Anon
()
Ответ на: комментарий от Manhunt

Юзеры знают о пакетном менеджере. Если ты не выкатил им готовый rpm/deb/tgz пакет, то ты.. обошелся с ними некрасиво.

это сферические юзеры в вакууме, существование которых не доказано. установка пакетов rpm/deb/tgz для технически неграмотного пользователя ничем не проще компиляции - для него и то и другое полная матрица. так что их во внимание не берем.

А сборка — для тех, кто знает, что делает. Она в любом случае требует довольно высокой квалификации, так что жаловаться не незнание команды cmake — это просто смешно. И ничто не мешает приложить файлик INSTALL с инструкцией.

дело не в квалификации, а в нестандартности системы сборки. автотулсы - стандарт де-факто. остальное эксперименты. и так будет, пока что-то другое не захватит флаг. и это точно будет не cmake.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

и это точно будет не cmake

Ты перейдешь на cmake, еще 100 человек перейдут... Глядишь, и останутся автотулзы только страшным сном.

Anon
()
Ответ на: комментарий от Anon

А, звиняй. Я даже не знаю, что эта цель должна делать.

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

А как у тебя получается, что архив репы больше архива нужных файлов?

в репе хранится множество файлов, нужных в процессе разработки, но не нужных конечному юзеру. все просто.

В скорости.

скорость тут вторичный фактор. скорость сборки автотулсами отличается от cmake только временем выполнения configure.

а вот надежность и удобство очень отличаются.

waker ★★★★★
() автор топика
Ответ на: комментарий от Anon

Ты перейдешь на cmake, еще 100 человек перейдут... Глядишь, и останутся автотулзы только страшным сном.

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

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

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

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

имеется ввиду AC_SUBST(OS)

А где тут «сборчные скрипты конкретных модулей»?

нет, нужно именно определение

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

Manhunt ★★★★★
()
Ответ на: комментарий от waker

он даже тарбол собрать не может

Можно наколхозить

Anon
()
Ответ на: комментарий от waker

установка пакетов rpm/deb/tgz для технически неграмотного пользователя ничем не проще компиляции

Она мышкой делается...

автотулсы - стандарт де-факто.

Были им 10 лет назад.

и так будет, пока что-то другое не захватит флаг. и это точно будет не cmake.

Победил базар, в котором приличную долю имеет cmake. Это состоявшийся факт.

Manhunt ★★★★★
()
Ответ на: комментарий от waker

в репе хранится множество файлов, нужных в процессе разработки, но не нужных конечному юзеру. все просто.

Конечному пользователю сорцы вообще нафиг не сдались.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Manhunt

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

нет, я про тарболлы - архивы с исходниками.

А где тут «сборчные скрипты конкретных модулей»?

в терминах autotools это Makefile.am каждого модуля. AC_SUBST делает так, что переменная экспортируется из autoconf в automake.

как там это называется в cmake - это уж вам виднее.

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

я имел ввиду это же самое, но другими словами. ок, есть так есть.

waker ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

Она мышкой делается...

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

Были им 10 лет назад.

а сейчас что? может померяем количество разных систем сборки в каком-нибудь portage? уверен, есть уже готовая статистика, и лидер в ней очевиден.

Победил базар, в котором приличную долю имеет cmake. Это состоявшийся факт.

что за базар?

waker ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

Конечному пользователю сорцы вообще нафиг не сдались.

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

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

что за базар?

Bazaar. Кое-что в арчиге с базара бралось. Сам не пользовался никогда.

Anon
()
Ответ на: комментарий от Anon

у меня возникла идея эксперимента, чтобы проверить вот это утверждение на практике:

возможность подключать 3rd-party библиотеки, как через pkg-config, так и без него

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


если они установлены в другой префикс нежели компилируемый проект

Да.

вот проект:

edit: извиняюсь, дал неправильный линк на git, исправил

http://git.make-linux.org/repos-pacman

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

с проектами на автотулсах проблем нет, с cmake у меня не получилось собрать в префикс $HOME/sde - при сборке через cmake не нашлись зависимости.

давай ты, или Manhunt, или обое два, попробуете собрать хотя бы waterline, и расскажете как вам это удалось.

я потратил на это 2 часа, и сдался.

если удастся — будет занятный результат эксперимента, по которому можно будет судить, насколько просто или сложно использовать cmake для юзера который в нем разбирается (вы двое), по сравнению с юзером который в нем не разбирается (я).

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

(нужно просто выставить PKG_CONFIG_PATH и LD_LIBRARY_PATH в prefix/lib и prefix/lib/pkgconfig соотв)

waker ★★★★★
() автор топика
Последнее исправление: waker (всего исправлений: 3)
Ответ на: комментарий от Anon

Дошло: это же только правила сборки пакета для арчега.

Anon
()
Ответ на: комментарий от waker
git clone http://git.make-linux.org/repos-pacman
Cloning into 'repos-pacman'...
fatal: http://git.make-linux.org/repos-pacman/info/refs not valid: is this a git repository?

Дай, плз, правильную ссылку

Anon
()
Ответ на: комментарий от Anon

в браузере открой. там на каждый компонент отдельный репозиторий. по ссылке список.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

Фигасе! Да это я только пару часов убью, чтобы при помощи гугля и такой-то матери разобраться с configure.ac, а потом ведь еще всю эту хрень надо запендорить для cmake'а!

Не, когда делаешь с нуля, все гораздо проще: постепенно обрастает подробностями.

Anon
()
Ответ на: комментарий от Anon

Фигасе! Да это я только пару часов убью, чтобы при помощи гугля и такой-то матери разобраться с configure.ac, а потом ведь еще всю эту хрень надо запендорить для cmake'а!

там не с чем разбираться — автотулсовые проекты просто работают.

там сначала надо собрать 1 или 2 мелких модуля на автотулсах, а следующий модуль уже cmake, и он обламывается.

# 1 раз выполнить это:
export LD_LIBRARY_PATH=$HOME/sde/lib
export PKG_CONFIG_PATH=$HOME/sde/lib/pkgconfig

# для каждого автотулс модуля:
./autogen.sh
./configure --prefix=$HOME/sde
make -j8
make install

# для каждого cmake модуля
???
waker ★★★★★
() автор топика
Последнее исправление: waker (всего исправлений: 2)
Ответ на: комментарий от waker

там не с чем разбираться

wc -l configure.ac 
414 configure.ac

Ага, ага.

???

Что-то вроде

mkdir tmp && cd tmp && cmake .. -Dprefix=$HOME/sde && make -j8 && make install
Anon
()
Ответ на: комментарий от Anon

ну запусти - увидишь.

если что - читать содержимое configure.ac вообще не нужно. оно и без этого прекрасно работает.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

оно и без этого прекрасно работает

Не лукавь:

mv configure.ac configure.ac- && ./autogen.sh
+ '[' x '!=' x ']'
+ aclocal
aclocal: error: 'configure.ac' is required
...

А cmake там ясен пень не заработает без CMakeLists.txt, в который нужно преобразовать твой configure.ac

Anon
()
Ответ на: комментарий от waker

Дык, а ты что хотел сказать? configure.ac у тебя — это практически то же самое (только с хитрожопым синтаксисом), что CMakeLists.txt у меня. И как ты предполагаешь автоматом преобразовать?

Anon
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.