<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Maxim,<br>
</p>
<br>
<div class="moz-cite-prefix">On 05/16/2018 12:24 PM, Maxim Dounin
wrote:<br>
</div>
<blockquote type="cite" cite="mid:20180516162415.GM32137@mdounin.ru">
<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>
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'.<br>
<br>
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.<br>
<br>
<br>
<br>
Thomas<br>
</body>
</html>