C
Comments 24
+2
Как по мне краткое введение не нужно, примеров предостаточно, да и они настолько тривиальны, что пояснения не нужны. А вот что-то более сложное, с зависимостями, раздельной компиляцией, проверкой версий и т.п. было бы полезнее. Лично я сколько раз не брался, столько-же раз бросал и продолжаю писать простые для понимания Makefile'ы или *sh скрипты.
+3
В одной статье всего не уместить, а писать про действительно сложные вещи имеет смысл только в рамках цикла статей, и далеко не в первую очередь, ибо требования к целостности и последовательности изложения никто не отменял, в противном случае всё превратится в бессвязный набор «полезных советов», которые могут быть поняты только теми, кто и так уже в теме.
+5
M4 это то кошмарное чудо, с помощью которого генерировался конфиг sendmail'а? И где для обозначения строки используются разнонаправленные кавычки? Жесть… Честно признаться не понимаю как это дожило до сих времён. Оно должно было умереть вместе с sendmail'ом…
Почему они не стали использовать хотя бы препроцессор С. Благо он везде есть…
+2
Оно самое, да. Макросы autoconf при этом достаточно короткие, т. к. используется модульный подход, а их вызовы так и вовсе однострочны в большинстве случаев. А для строк используются не кавычки, а [квадратные скобки], что, в принципе, является не сколько обозначением строки, сколько инструкцией не пытаться распознать содержимое как вызов макроса.
+3
Ну, если кто-то еще никак не может закопать обратно стюардессу, то это их проблемы.
Именно из-за безумного конфига sendmail' и столь же безумного генератора конфигов на М4 я свалил на postfix. Но sendmail и М4 мне еще долго снились… Я отлично понимаю почему народ тупо копипастит конфиги m4.
+2
Они не считают, что это в принципе «проблемы». Могу привести хороший пример: FreeBSD. Стюардесса не менее мертва, но у нее несть числа поклонников в России.
0
Я сам адепт FreeBSD. ) Sendmail там оставляют только те, кому от него ничего большего не требуется, чем он может в стандартной конфигурации. Все, кто более-менее серьезно работает с почтой, сразу его меняют на postfix или qmail.

Впрочем… Но мы его к почтовым серверам не подпускаем…
0
Мне стыдно. Топик это одно из того, что никак не смог осилить полностью. Конечно мог изменить существующие конфиги под себя. Но не смотря на понимание отдельных моментов — в целом, никак не лезет в голову. Особенно проблемы на подобии: если есть lib1 использовать её, иначе lib2… в крайнем случае lib5.

Прочитал статью, и вспомнились тёплые ламповые времена. Осознал, на сколько продвинулись среды и тулчейны разработки.
+1
Эм, оно жеж config.h с информацией о наличии библиотек генерирует, дальше можно определиться на ifdef-ах.
+3
Есть хороший мануал в виде презентации по autoconf: PDF
Читается быстро и легко, разъясняются многие тонкие моменты и то, как происходит все внутри. Очень рекомендую новичкам.
UFO landed and left these words here
0
Я бы посоветовал использовать install -D

Это пригодится, если вы решите поставить проект в несуществующую директорию, например в /home/username/pkgs

И еще, кажется здесь
install:
install hellolog $(DESTDIR)$(bindir)/hellolog

вы хотели написать prefix вместо DESTDIR
0
prefix уже содержится в bindir, его туда autoconf кладёт. DESTDIR нужен для того, чтобы скрипт сборки пакета мог установить файлы во временную директорию.
0
Честно говоря не совсем понимаю зачем это нужно, мы же и так можем регулировать куда положить пакет с помощью ./configure --prefix=something, зачем нужен еще и$(DESTDIR)?
+1
Ну вот смотрите. Допустим, мы хотим, чтобы программа была установлена в /opt/prog, тогда конфигурационные файлы будут лежать в /opt/prog/etc. Этот путь (заданный через параметры ./configure) оказывается вкомпилированным в исполняемый файл, он там потом их будет после запуска искать. Теперь вспоминаем про то, что большинство дистрибутивов укомплектованы пакетными менеджерами, оперирующими бинарными пакетами, и, по-хорошему, нам вместо того, чтобы засирать систему, нужно использовать их возможности. При сборке пакета, чтобы в нём не оказалось ничего лишнего, относящиеся нему файлы надо положить в отдельную директорию, откуда они потом попадут в архив (внутри deb помимо метаданных и скриптов лежит обычный tar.gz с файлами, в RPM используется cpio). Соответственно надо как-то проинструктировать make install о том, куда ему класть файлы. Через --prefix мы этого сделать не можем, потому что тогда скомпилированный исполняемый файл будет искать свои данные в /tmp/debuild-root/mypackage/debian/tmp/opt/prog/etc, где их после установки пакета, естественно, не будет. Потому нужен какой-то иной способ указать, куда именно сейчас складывать файлы. Этим способом и является переменная DESTDIR.
0
Все понял идею, спасибо за объяснение. Я честно говоря не занимался создание deb пакетов, поэтому с данной схемой не знаком. Еще раз спасибо за разъяснение.
0
Да эта схема во всех бинарных дистрибутивах одна и та же. Единственная альтернатива — смонтировать куда-нибудь корень через --rbind, поверх него unionfs, сделать туда chroot, а потом уже внутри make install. Но это слишком заморочено и плохо переносимо между операционками, потому все пользуются стандартными инструментами сред сборки.
0
die — артикль не множественного числа, а женского рода в номинативе.
Множественное число определяется окончанием, причем у разных слов разным.
0
Да вы что? (подсказка: смотреть правый верхний угол). Я, может, многое успел забыть, но два курса проведённых на инязе даром не проходят.
UFO landed and left these words here
0
Autotools — название/имя собственное, их не переводят. И тогда уж не Autotoolsen, а Selbstwerkzeuge
Only those users with full accounts are able to leave comments. , please.