<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>