Openresty downstream bundle maintenance requests

[Nginx User]

On Sat, Sep 17, 2011 at 4:58 PM, agentzh <agentzh at gmail.com> wrote:

> On Sat, Sep 17, 2011 at 4:53 PM, Nginx User <nginx at nginxuser.net> wrote:
> > The configure script under the "for my $opt (@ARGV) {" loop covers a few
> > typical items and any others cause the "die "Invalid option $opt\n";"
> line
> > to be triggered. However, when in a Fedora/Enterprise Linux build
> > environment, the "%configure" macro in the spec file adds several other
> > switches (which work fine when building nginx directly).
>
> Which options do not work for you? The last part in that loop is actually:
>
>    } elsif ($opt =~ /^--\w.*/) {
>         push @ngx_opts, $opt;
>
>    } else {
>        die "Invalid option $opt\n";
>    }
>
> That is, any options starting with a /\w/ will be matched in the last
> 2nd condition and passed to nginx's configure script.
>

Correct and it matches all the "--with XYZ" and "--without XYZ" flags for
nginx.


> > Can the upstream please consider modifying  the configure script to allow
> > for these?
> > A possiblity is:
> > for my $opt (@ARGV) {
> > ...
> >     } elsif ($opt =~ /^--build=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--host=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--target=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--program-prefix=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--exec-prefix=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--bindir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--sbindir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--sysconfdir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--datadir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--includedir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--libexecdir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--localstatedir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--sharedstatedir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--mandir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } elsif ($opt =~ /^--infodir=(.*)/) {
> >         push @ngx_opts, $opt;
> >     } else {
> >         die "Invalid option $opt\n";
> >     }
> > }
>
> These options should be happily accepted by the last 2nd option. If
> not, please let me know :)
>

They are matched by the last option of 'die "Invalid option $opt\n";' .


>
> > Also, can the upstream consider dropping version numbers from the folders
> in
> > the "bundle" directory and record the version numbers in a README? Would
> > save having to edit the spec file for every release.
>
> Okay, I'll remove version numbers in my build script in the next
> release of ngx_openresty :)
>

No longer required thanks.


>
> > Finally, can the upstream consider allowing the with luajit option to be
> > selected but not to try to build luajit? I.E. set openresty up to use
> luajit
> > but have the luajit build done separately and not try to replace this by
> the
> > standard lua. I suppose the same applies to the standard lua. Basically,
> > third party applications should ideally be built separately and we would
> > look into creating seperate rpms for those.
>
> Will adding new options like --with-luajit=PATH and --with-lua51=PATH
> work for you? That is, telling ngx_openresty to use an external luajit
> or lua 5.1 build located by PATH?
>

This should work. We can then switch piar this with --without luajit. We
obviously want to keep the lua-rds-parser and lua-redis options.


>
> By default, ngx_openresty will continue try to build its bundled
> version of LuaJIT or Lua 5.1 and use it whenever possible and that's
> the whole point of a bundle ;) But I'm still willing to add special
> options to help RPM/Debian/etc packaging for sure :)
>
> > Can foresee some potential
> > knotty issues to overcome with this but if distributing an rpm, then
> there
> > are issues anyway.
>
> I'm very willing to help and solve any issues along the way ;)
>
> Thanks!
> -agentzh
>

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20110917/8e0bcac9/attachment.html>