Openresty downstream bundle maintenance requests

[Nginx User]

Hi.

A few things to consider with respect to downstream maintenance support.

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

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";
    }
}

May be even merge all the "dir" ones into "} elsif ($opt =~
/^--(.*)dir=(.*)/) {"

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.

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. Can foresee some potential
knotty issues to overcome with this but if distributing an rpm, then there
are issues anyway.

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