Interesting, that wasn't in the specific rules when I was hunting it down.

Thanks for the pointer.  In either case, it should probably be enabled
globally, per my prior arguments (but with respect to downstream distros)


On 05/16/2018 01:14 PM, Maxim Dounin wrote:
> Hello!
>
> On Wed, May 16, 2018 at 12:45:11PM -0400, Thomas Ward wrote:
>
>> Maxim,
>>
>>
>> On 05/16/2018 12:24 PM, Maxim Dounin wrote:
>>> Hello!
>>>
>>> On Wed, May 16, 2018 at 12:03:51PM -0400, Thomas Ward wrote:
>>>
>>>> On 05/10/2018 08:47 AM, Maxim Dounin wrote:
>>>>> 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.
>>>> 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?
>>> 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.
>>>
>> 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.
> Repositories as available from nginx.org are built with
> "--with-compat" since it was introduced in 2016:
>
> http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/Makefile#l256
> http://hg.nginx.org/pkg-oss/rev/fa656182ba2a#l3.220
>

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel