<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Interesting, that wasn't in the specific rules when I was hunting
it down.</p>
<p>Thanks for the pointer.š In either case, it should probably be
enabled globally, per my prior arguments (but with respect to
downstream distros)<br>
</p>
<br>
<div class="moz-cite-prefix">On 05/16/2018 01:14 PM, Maxim Dounin
wrote:<br>
</div>
<blockquote type="cite" cite="mid:20180516171443.GP32137@mdounin.ru">
<pre wrap="">Hello!
On Wed, May 16, 2018 at 12:45:11PM -0400, Thomas Ward wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Maxim,
On 05/16/2018 12:24 PM, Maxim Dounin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello!
On Wed, May 16, 2018 at 12:03:51PM -0400, Thomas Ward wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/10/2018 08:47 AM, Maxim Dounin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">More importantly, "--with-compat" provides compatibility between
builds with different configure options.
Without the "--with-compat" argument, one have to use exactly the
same "./configure" line to build both nginx and a module. The
"--with-compat" option relaxes this restriction, and it is more or
less enough to build both nginx and a module with "--with-compat".
This generally simplifies building dynamic modules, and also
allows one to load the same module into different nginx variants
built with different flags.
</pre>
</blockquote>
<pre wrap="">Is there a reason, then, that `--with-compat` is not a default build
option?š Is there a particular specific reason it was *not* set as a
default compile-time option?
</pre>
</blockquote>
<pre wrap="">The main reasons are that "--with-compat" is not needed when not
using dynamic modules built separately, and compiling nginx with
"--with-compat" results in slightly less optimal binaries (with
various otherwise unneeded placeholder fields added to
structures).
We've considered making it the default when it was introduced, but
decided to keep it as an explicit option then. This might worth
reconsidering.
</pre>
</blockquote>
<pre wrap="">I agree it might be worth a reconsideration, in fact I am a supporter of
making `--with-compat` a default option, not only to make my job as a
downstream packager easy, but because this would also benefit the
nginx.org open-source nginx repository as well.š With the number of
third-party dynamic modules increasing, and more users wanting to
utilize them, it may be detrimental to leave it disabled.š When the
support was first released, and dynamic modules were 'new', it made
sense to leave it disabled, but with more and more modules becoming
dynamically-supported it could be detrimental to leave this 'default
disabled'.
With specific regard to the nginx.org repositories, at last I checked a
couple weeks ago, they aren't currently built with `--with-compat`
(unless I missed a recent change to the OSS packaging on hg.nginx.org),
which means it's equally difficult for users to use the nginx
repositories without compiling NGINX themselves with third-party
modules.š If with-compat becomes the default, then this makes things
easier for users using the nginx.org repos as well as other downstream
distributions' packages going forward.
</pre>
</blockquote>
<pre wrap="">
Repositories as available from nginx.org are built with
"--with-compat" since it was introduced in 2016:
<a class="moz-txt-link-freetext" href="http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/Makefile#l256">http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/Makefile#l256</a>
<a class="moz-txt-link-freetext" href="http://hg.nginx.org/pkg-oss/rev/fa656182ba2a#l3.220">http://hg.nginx.org/pkg-oss/rev/fa656182ba2a#l3.220</a>
</pre>
</blockquote>
<br>
</body>
</html>