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? там что-то свое, или у него есть сайт?

★★★★★

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

чем отличается «стандарт» от «стандарта де-факто», надеюсь, в курсе?

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

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

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

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

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

Лично тебе никто ничего доказывать не будет. man-страница доступна, примеры сборки кроссом доступны (в том же mxe есть готовый toolchain-файл).

каким образом и в какой параллельной реальности люди избавляются от автотулс?

Notable applications

  • Allegro library
  • AliRoot - HEP package being used by ALICE LHC experiment at CERN
  • Armadillo - linear algebra library
  • Avidemux
  • awesome - window manager
  • Blender
  • BRL-CAD
  • Bullet Physics Engine
  • Chicken Scheme
  • Chipmunk physics engine
  • Compiz
  • Conky
  • cURL
  • Doomsday Engine
  • Dust Racing 2D
  • Drishti
  • Falcon (programming language)
  • Gammu
  • GDCM
  • Geant4
  • Gmsh
  • GNU Radio
  • Hypertable
  • Hugin
  • iCub robot and YARP
  • IGSTK
  • Insight Segmentation and Registration Toolkit (ITK)
  • KDE SC 4
  • KiCad
  • libpng
  • LMMS
  • LLVM and Clang
  • Mir
  • MiKTeX
  • MuseScore
  • MySQL and MariaDB
  • OGRE
  • OpenSceneGraph
  • OpenSync
  • OpenCV
  • OpenCog
  • Orthanc
  • Point Cloud Library
  • Polycode
  • Poppler
  • PvPGN
  • Quantum GIS
  • Qt5
  • Raw Therapee
  • ReactOS
  • ROOT
  • ROS
  • Scribus
  • Second Life
  • SFML
  • Spring RTS
  • SuperTux
  • Slicer
  • Stellarium
  • Trilinos
  • The Visualization Toolkit and ParaView
  • VXL
  • zlib
  • PCSX2
  • Zdoom
  • ZMQ
Manhunt ★★★★★
()
Ответ на: комментарий от AptGet

Там и то, и то:

ls
aclocal.m4   CMakeLists.txt  configure.ac  install-sh*        libpngpf.3   missing*    pngconf.h   pnginfo.h   pngread.c   pngstruct.h  pngwio.c    README
ANNOUNCE     config.guess*   contrib/      libpng.3           LICENSE      png.5       pngdebug.h  pngmem.c    pngrio.c    pngtest.c    pngwrite.c  scripts/
arm/         config.h.in     depcomp*      libpng-config.in   ltmain.sh    pngbar.jpg  pngerror.c  pngnow.png  pngrtran.c  pngtest.png  pngwtran.c  test-driver
autogen.sh*  config.sub*     example.c     libpng-manual.txt  Makefile.am  pngbar.png  pngget.c    pngpread.c  pngrutil.c  pngtrans.c   pngwutil.c  tests/
CHANGES      configure*      INSTALL       libpng.pc.in       Makefile.in  png.c       png.h       pngpriv.h   pngset.c    pngusr.dfa   projects/   TODO

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

Кстати, вот где можно явно показать, что cmake удобней для конечного пользователя:

cat testcmake 
#!/bin/bash
mkdir tmp && cd tmp && cmake .. && make

cat testauto  
#!/bin/bash
./configure && make
time ./testcmake
...
real	0m4.943s
user	0m4.344s
sys	0m0.427s

time ./testauto
...
real	0m13.974s
user	0m12.161s
sys	0m0.720s
Anon
()
Ответ на: комментарий от waker

какие из этих проектов перешли с автотулзов?

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

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

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

не вижу киллер-фич по сравнению с autotools

Конфигурение происходит гораздо быстрее (в десятки раз).
Заметно лучше работает make -jN (для крупных проектов это ппц как актуально).
Гораздо ниже порог вхождения.

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

Конфигурение происходит гораздо быстрее (в десятки раз).

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

Заметно лучше работает make -jN (для крупных проектов это ппц как актуально).

Эээ... что-то меня это «лучше» пугает %)

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

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

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

Заметно лучше работает make -jN (для крупных проектов это ппц как актуально).

у тебя cmake какой-то особенный, и использует другой make? как это оно может по-разному работать? постоянно собираю все с -j8, и даже не подозревал что оно работает «хуже» чем make в cmake.

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

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

Зависит от структуры собираемого проекта. Посмотри, сколько времени на конфигурение тратит какой-нибудь gcc.

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

Заметно лучше работает make -jN (для крупных проектов это ппц как актуально).

у тебя cmake какой-то особенный, и использует другой make? как это оно может по-разному работать? постоянно собираю все с -j8, и даже не подозревал что оно работает «хуже» чем make в cmake.

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

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

а директории перебираются последовательно.

Да уймись ты, болван!

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

Всё параллельно, никаких директорий.

Всё одной портянкой? Это успех, да :D

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

1. Вынужден отправить читать мануал Automake ещё раз.

2. Ты даже не представляешь, какая задача решалась. Так что на «портянку» насрать.

3. Редактировать один файл удобнее

4. Это выглядит как портянка только для тех, кто не умеет читать.

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

я всего лишь имел ввиду что портянка далеко не всегда и не в любом проекте подходит. так-то ясен хрен, что c 1 Makefile не может быть проблем, которые есть с несколькими Makefiles.

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

вас смущает слово портянка? думаю, Manhunt (и я вслед за ним) употребили ее в смысле «все в 1 файле», а не в смысле «нечитаемо». так что ваша ссылка не особо в тему. я синтаксис автотулсов достаточно неплохо знаю, и ежедневно применяю.

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

Рекомендую вам обоим освоить и cmake, и autotools, а потом сраться.

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

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

Редактировать один файл удобнее

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

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

это 100%?

Анонимус отчасти прав: я имел ввиду случай, когда для каждой директории заведен отдельный Makefile, и используется recursive make. Насколько я понял, автотулзы рекомендуют решать эту проблему при помощи портянки: https://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html

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

я в курсе про возможность nonrecursive make, но в моем проекте это бы вылилось в файл на ~2600 строк, с которым работать было бы намного менее удобно.

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

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

Да, кочергой вас по голени!

automake умеет include.

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

ок, 1 шт. вычислили :)

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

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

А еще:

  • "The CmakeLists.txt files are models of clarity and only require you to add the name of a file once, where makefile.am requires three different entries for a single file."
  • "Speed - on my quite ordinary Linux system it takes 5-7 seconds to generate all the makefiles for Scribus, compared to 30-50 seconds for auto*"
  • "Much more useful error messages when you make a mistake in editing files. Auto* error messages have been known to drive developers to a state of madness trying to fix the errors."
  • "Smaller makefiles. 57kb for the main Scribus makefile from cmake vs 257kb from auto* In the future, compiling Scribus with cmake is as simple as:

По сути, то, что я уже неоднократно говорил: синтаксис проще, скорость выше, про ошибки не сказал бы так (иной раз тоже хрен поймешь, где налажал); про makefile'ы тоже не сказал бы (точнее, мне пофиг, какой у них размер — лишь бы компилялось быстро).

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

Ну а кто в здравом уме будет такие списки помнить?

На вскидку я еще jpeg-turbo могу припомнить. Он собирается как autotools так и cmake. Но кросбилд с помощью автотулзов не работоспособен. В багтрекере по этому поводу написано - не парьтейсь и собирайте cmake`ом, там все работает, мы проверяли.

Тот факт, что autotools - стандрат де факто, еще не означает, что там все так гладко. Мне вот приходилось числодробилки из фортрана вытягивать. Ибо тоже долгое время был стандарт. Но это же не повод писать свои, новые, числодробилки на фортране?

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

Но это же не повод писать свои, новые, числодробилки на фортране?

Ага. Еще и с CUDA'й ☺

// а все-таки, до сих пор значительную долю GSL'я составляют фортрановские тексты. Их просто "наследуют", никому неохота связываться с переписыванием кучи кода на нормальный ЯП.

Anon
()

Фанаты CMake (как и питона, но это отдельный разговор) - это же сектанты. Им пишешь что плохо что-то работает, а в ответ «да у тебя руки кривые!», «УМВР!», «вот уже ХХХ перешли на CMake!»

Boost кстати как-то переходил на CMake, как там все прошло, нормально?

Мне пару лет назад нужно было собирать простую софтину на линуксе, винде (мингв/мсис) и опенбзд. Зависимостей мало, bison(опционально), OpenSSL и какая-то еще мелочевка. Попробовал собирать цмейком и мягко говоря пожалел. Библиотеки он искал плохо везде, в OpenBSD-шных пакетах вообще была какая-то древняя жесть, пришлось дня два упарываться манами и делать так чтоб софтина везде собиралась одной командой. С автотулс как-то проще, погуглил слегка и все заработало

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

нормальный ЯП.

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

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

значительную долю GSL'я составляют фортрановские тексты

что же с тобой случилось?

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

синтаксис проще

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

скорость выше

это уже обсосали.

про ошибки не сказал бы так (иной раз тоже хрен поймешь, где налажал);

угу, с этим в cmake по-дефолту хуже.

про makefile'ы тоже не сказал бы (точнее, мне пофиг, какой у них размер — лишь бы компилялось быстро).

ага, я тоже не заметил особо, чтобы cmakelists были короче.

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

Тот факт, что autotools - стандрат де факто, еще не означает, что там все так гладко. Мне вот приходилось числодробилки из фортрана вытягивать. Ибо тоже долгое время был стандарт. Но это же не повод писать свои, новые, числодробилки на фортране?

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

Мне вот приходилось числодробилки из фортрана вытягивать. Ибо тоже долгое время был стандарт. Но это же не повод писать свои, новые, числодробилки на фортране?

если фортрану есть более адекватная замена — то однозначно новые лучше писать на ней. в случае с autotools vs cmake все не так однозначно.

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

Фанаты CMake (как и питона

мне иногда кажется, что это одни и те же люди.

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

Ну а кто в здравом уме будет такие списки помнить?

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

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

фортрану есть более адекватная замена
в случае с autotools vs cmake все не так однозначно

Можно подумать, с фортраном однозначно!

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

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

Такое бывает не только с системами сборки. У меня есть парочку коллег, которые любят говорить - «Какой такой баг? Ниче не знаю, у меня на компе все работает». Так шо набыдлокодить можно на любом языке.

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

Ты говорил о разнице в скорости. Для сравнения нельзя взять какой-то проект на cmake и сравнить его время сборки с каким-то другим проектом на autotools — так можно получить любые цифры. Надо взять проекты, в которых одновременно поддерживаются две системы сборки, и для каждого из них сравнить время сборки cmake и autotools. GCC, вроде бы, не поддерживает cmake — надо сначала добавить полнофункциональную поддержку сборки cmake, и лишь потом сравнивать.

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

LLVM поддерживает autotools и cmake.

Точнее, из тулзов там только autoconf.

unsigned ★★★★
()
Последнее исправление: unsigned (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.