LINUX.ORG.RU

[autotools] Нужен ли libtool?

 


0

0

Пишу библиотеку, использую automake. Вместе с ним настоятельно рекомендуют использовать libtool, но мне эта вещь совсем не понравилась. Есть ли причины пользоваться ей в 2010 году?

Кажется, все, что дает libtool - это поддержка всех существующих платформ, из которых большинство уже умерло, а оставшиеся пришли к более-менее единому стандарту. По крайней мере, на linux и *BSD сборка делается одной и той же командой.

А если отказаться от libtool, то как быть с automake? Достаточно ли добавить в Makefile.am

libmx.so       : expr.c var.c func.c module.c list.c
    $(CC) -I.. -fpic -shared -o $@ $^
? Это кроссплатформенно (для живых систем)?

(Вопрос только по autotools, предполагается, что они нужны ))

★★★★

Почти все библиотеки, которые я видел, пользуются libtool, но при этом у меня в системе почти нет *.la файлов. Видимо, их выкидывают мэйнтейнеры, что тоже более говорит против libtool.

unsigned ★★★★
() автор топика

Используй cmake, Luke.

Zodd ★★★★★
()

Вопрос следует ставить иначе: нужен ли в 2010 году automake? Если да, то пожалуй и libtool не помешает.

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

Задачи все же разные. automake помогает в сборке, а libtool лишь поддерживает всякие HP-UX, поэтому польза неочевидна. А особенно не нравится, что он устанавливает свои архивы (*.la), которые нужны еще меньше.

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

Когда человек в 2010 году пишет проект использую automake мне думается одно из двух: он олдовый гуру и как настоящий джедай умеет и automake, и libtool или же ему нужна поддержка всяких HP-UX'ов и прочей вымирающей экзотики. Попробуйте использовать cmake. Он проще, быстрее и умеет генерировать помимо Makefile'ов всякую бяку типо проектов студии.

KblCb ★★★★★
()

Если не использовать libtool, то и automake тоже не стоит. Напишите makefile.in руками, если под gmake - то это не очень сложно. KDE в свое время пытались написать замену automake+libtool, но плюнули и перешли на CMake. Я сейчас задумываюсь о переходе на Bakefile, чтобы генерировать configure.in + кучу всякой ерунды типа VCproj.

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

Угу. Это показатель.

http://oreilly.com/catalog/9780596806408
http://oreilly.com/catalog/9780735626690
http://oreilly.com/catalog/9781593272111
http://oreilly.com/catalog/9781449380144

Они готовы напечатать что угодно. Хоть учёбник по тому как правильно заниматься онанизмом левой рукой.

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

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

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

Если не использовать libtool, то и automake тоже не стоит

Действительно, получается черти что. Но gmake - это уже некроссплатформенно.

Bakefile

XML :( Заявлено вроде то же самое, что у cmake, он чем-то лучше?

unsigned ★★★★
() автор топика

ну, libtool, точнее ltdl из его состава ещё может быть нужен для организации загрузки плагинов. То есть, функциональность, аналогичная dlopen/dlsym/dlclose, но:
1) кроссплатформенная
2) можно слинковать с .a библиотекой, как будто бы она .so.
Пример: http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_onc...

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

Но почти все ключевые пакеты GNU пользуются им.

И? Почти все проекты в рамках KDE пользуются cmake. У ядро вроде бы вообще собственный лисопед. У проекта GNU есть некий Guideline, который сформировался уже очень давно. Если вы пишите что-то в рамках GNU то пожалуй automake + libtool ваш выбор.

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

http://sources.redhat.com/autobook/autobook/autobook_35.html#SEC35

It also implements some best practices as well as workarounds for vendor make bugs

http://www.linux.org.ru/books/GNU/automake/automake-ru_2.html

Заметьте, что расширения GNU make не распознаются программой Automake. Использование таких расширений в файле `Makefile.am' приведет к ошибкам или странному поведению.

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

> http://sources.redhat.com/autobook/autobook/autobook_35.html#SEC35

неочевидно

Использование таких расширений в файле `Makefile.am' приведет к ошибкам или странному поведению.

какая разница что там в Makefile.am, главное что на выходе в Makefile

известно, что на FreeBSD весь гнутый софт собирается исключительно gmake'ом, а это не спроста

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

Более явно ничего не нахожу, в доках четко написано лишь о совместимости с GNU Coding Standarts, которые нет желания читать. Может, и правда на не-GNU софт забили.

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

> известно, что на FreeBSD весь гнутый софт собирается исключительно gmake'ом, а это не спроста

По-моему, там у людей просто привычка - для портов с GNU_CONFIGURE сразу писать USE_GMAKE. На самом деле большинство замечательно собираются BSD'шным make. Хотя это (ставить USE_GMAKE) может и правильно - меньше вероятность наступить на грабли при обновлении порта, когда какой-нибудь криворукий любитель автотулзов нагадит GNU'тым мусором в Makefile.am. Вот cmake генерит 100% портабельные мэйкфайлы, и, возвращаясь к теме топика - да libtool кошмарное монстроидальное уродство, и не нужен, как автотулс в общем. libltdl разве что можно оставить.

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

Его проще таскать в виде исходников с собой. И он умеет генерировать autotools-овые проекты, а это удобно если надо собирать на машине без bakefile/cmake/... Ну и кросс-компиляция в autotools удобнее чем в cmake.

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