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
