Данный пост, скорее, обращение к Максиму, т.к. именно он закрыл связанный с
тем, о чём пойдёт речь, баг: ( https://trac.nginx.org/nginx/ticket/961 ), но я
так же приглашаю остальных участников рассылки высказать свои мысли по этому
поводу.
Суть же моего обращения в том, что в данном вопросе я, всё же, больше
солидарен с ожиданиями автора бага, нежели с решением команды разработки, и
думаю, что фича в виде установки c `--modules-path` не только пути установки
модулей, но и пути, по которому NginX будет их искать - довольно логична.
Стандартно, многие linux-системы собирают софт с `--prefix=/usr` и т.п. (в
общем, разбивкой служебных путей по разным частям фс). Порой на это даже
трудно повлиять, не переделывая билдскрипты.
В общем, "среднестатистическая" линуксовая сборка NginX выглядит так:
```
--prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/
nginx/error.log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --
with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib64 --http-log-path=/var/
log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client --
http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/
lib/nginx/tmp/fastcgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --http-
uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
```
При этом подразумевается, что свои модули и прочие "свои" файлы софт будет
хранить не в системных директориях, а в своих поддиректориях.
В случае же NginX, при обычной сборке, modules_path получается /usr/modules (я
так догадываюсь, из-за того, что по умолчанию оно имеет значение $prefix/
modules).
В итоге получается крайне не логичный путь, как по мне. Что ещё за /usr/
modules?
Тут на помощь приходит `--modules_path`. Но, к сожалению, после установки
NginX всё равно будет пытаться искать файлы относительно префикса. И класть
там симлинк - тот ещё костыль и равноценен тому, чтобы поставить их туда
напрямую (см. довод про нелогичность пути).
В случае инклуда конфигов, к слову, nginx вполне логично ищет их в /etc/nginx,
а не в prefix (хотя надо уточнить, не дистрибутивный ли патч фиксит это
поведение).
Так почему бы не сделать такое же по смыслу и для модулей? Чтобы не
провоцировать кучу лишней писанины на пустом месте :)
====
Так же, можно было бы на этапе сборки хардкодить расширение динамических
библиотек (so, dll, dylib), и так же не заставлять конфигописателя указывать
этот суффикс в конфиге, а просто конкатенировать параметр load_module (если он
в виде относительного, а не абсолютного пути) с "modules_path" спереди и
shared_suffix на конце.
Что думаете?
// особенно Максим
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
тем, о чём пойдёт речь, баг: ( https://trac.nginx.org/nginx/ticket/961 ), но я
так же приглашаю остальных участников рассылки высказать свои мысли по этому
поводу.
Суть же моего обращения в том, что в данном вопросе я, всё же, больше
солидарен с ожиданиями автора бага, нежели с решением команды разработки, и
думаю, что фича в виде установки c `--modules-path` не только пути установки
модулей, но и пути, по которому NginX будет их искать - довольно логична.
Стандартно, многие linux-системы собирают софт с `--prefix=/usr` и т.п. (в
общем, разбивкой служебных путей по разным частям фс). Порой на это даже
трудно повлиять, не переделывая билдскрипты.
В общем, "среднестатистическая" линуксовая сборка NginX выглядит так:
```
--prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/
nginx/error.log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --
with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib64 --http-log-path=/var/
log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client --
http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/
lib/nginx/tmp/fastcgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --http-
uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
```
При этом подразумевается, что свои модули и прочие "свои" файлы софт будет
хранить не в системных директориях, а в своих поддиректориях.
В случае же NginX, при обычной сборке, modules_path получается /usr/modules (я
так догадываюсь, из-за того, что по умолчанию оно имеет значение $prefix/
modules).
В итоге получается крайне не логичный путь, как по мне. Что ещё за /usr/
modules?
Тут на помощь приходит `--modules_path`. Но, к сожалению, после установки
NginX всё равно будет пытаться искать файлы относительно префикса. И класть
там симлинк - тот ещё костыль и равноценен тому, чтобы поставить их туда
напрямую (см. довод про нелогичность пути).
В случае инклуда конфигов, к слову, nginx вполне логично ищет их в /etc/nginx,
а не в prefix (хотя надо уточнить, не дистрибутивный ли патч фиксит это
поведение).
Так почему бы не сделать такое же по смыслу и для модулей? Чтобы не
провоцировать кучу лишней писанины на пустом месте :)
====
Так же, можно было бы на этапе сборки хардкодить расширение динамических
библиотек (so, dll, dylib), и так же не заставлять конфигописателя указывать
этот суффикс в конфиге, а просто конкатенировать параметр load_module (если он
в виде относительного, а не абсолютного пути) с "modules_path" спереди и
shared_suffix на конце.
Что думаете?
// особенно Максим
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru