<div dir="ltr"><br><br><div class="gmail_quote">On Sat, Sep 17, 2011 at 4:58 PM, agentzh <span dir="ltr"><<a href="mailto:agentzh@gmail.com">agentzh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sat, Sep 17, 2011 at 4:53 PM, Nginx User <<a href="mailto:nginx@nginxuser.net">nginx@nginxuser.net</a>> wrote:<br>
> The configure script under the "for my $opt (@ARGV) {" loop covers a few<br>
> typical items and any others cause the "die "Invalid option $opt\n";" line<br>
> to be triggered. However, when in a Fedora/Enterprise Linux build<br>
> environment, the "%configure" macro in the spec file adds several other<br>
> switches (which work fine when building nginx directly).<br>
<br>
</div>Which options do not work for you? The last part in that loop is actually:<br>
<br>
} elsif ($opt =~ /^--\w.*/) {<br>
<div class="im"> push @ngx_opts, $opt;<br>
<br>
} else {<br>
die "Invalid option $opt\n";<br>
}<br>
<br>
</div>That is, any options starting with a /\w/ will be matched in the last<br>
2nd condition and passed to nginx's configure script.<br></blockquote><div><br></div><div>Correct and it matches all the "--with XYZ" and "--without XYZ" flags for nginx.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
> Can the upstream please consider modifying the configure script to allow<br>
> for these?<br>
> A possiblity is:<br>
> for my $opt (@ARGV) {<br>
> ...<br>
> } elsif ($opt =~ /^--build=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--host=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--target=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--program-prefix=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--exec-prefix=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--bindir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--sbindir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--sysconfdir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--datadir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--includedir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--libexecdir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--localstatedir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--sharedstatedir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--mandir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } elsif ($opt =~ /^--infodir=(.*)/) {<br>
> push @ngx_opts, $opt;<br>
> } else {<br>
> die "Invalid option $opt\n";<br>
> }<br>
> }<br>
<br>
</div></div>These options should be happily accepted by the last 2nd option. If<br>
not, please let me know :)<br></blockquote><div> </div><div>They are matched by the last option of 'die "Invalid option $opt\n";' .</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Also, can the upstream consider dropping version numbers from the folders in<br>
> the "bundle" directory and record the version numbers in a README? Would<br>
> save having to edit the spec file for every release.<br>
<br>
</div>Okay, I'll remove version numbers in my build script in the next<br>
release of ngx_openresty :)<br></blockquote><div> </div><div>No longer required thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Finally, can the upstream consider allowing the with luajit option to be<br>
> selected but not to try to build luajit? I.E. set openresty up to use luajit<br>
> but have the luajit build done separately and not try to replace this by the<br>
> standard lua. I suppose the same applies to the standard lua. Basically,<br>
> third party applications should ideally be built separately and we would<br>
> look into creating seperate rpms for those.<br>
<br>
</div>Will adding new options like --with-luajit=PATH and --with-lua51=PATH<br>
work for you? That is, telling ngx_openresty to use an external luajit<br>
or lua 5.1 build located by PATH?<br></blockquote><div><br></div><div>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.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
By default, ngx_openresty will continue try to build its bundled<br>
version of LuaJIT or Lua 5.1 and use it whenever possible and that's<br>
the whole point of a bundle ;) But I'm still willing to add special<br>
options to help RPM/Debian/etc packaging for sure :)<br>
<div class="im"><br>
> Can foresee some potential<br>
> knotty issues to overcome with this but if distributing an rpm, then there<br>
> are issues anyway.<br>
<br>
</div>I'm very willing to help and solve any issues along the way ;)<br>
<br>
Thanks!<br>
<font color="#888888">-agentzh<br></font></blockquote><div><br></div><div>Thanks! </div></div><br></div>