Stas Bekman wrote:
Philippe M. Chiasson wrote:
[...]
Doug will still handle the release management. What we need help
with, is
maintaining the STATUS file and verifying and following up on
submitted patches so not to discourage contributions. (again talking
mod_perl 1.0 here).
Isn't Geof
ok, but I don't understand why this can't follow the same mechanics of
attributes, since they work just fine for the other stuff.
It's not the same. Currently we use attributes to learn whether the
handler is designed for Request or Connection. But we already know the
name of the handler. So
Hello,
When i want to define a multi argument configuration directive using
perl, i have to use an array variable:
@DirectoryIndex = ("foo", "bar");
But if this directive is used inside a section, i have to use an
anonymous array:
$Directory{"flup} = {
DirectoryIndex => [ "foo", "bar" ]
};
Geoffrey Young wrote:
ok, but I don't understand why this can't follow the same mechanics
of attributes, since they work just fine for the other stuff.
It's not the same. Currently we use attributes to learn whether the
handler is designed for Request or Connection. But we already know the
Hi,
Visual Studio (and I think some other compilers) like to
have variables declared up front. This diff
===
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvspublic/
Just noticed that specifying PREFIX to perl Makefile.PL doesn't quite
work all the time. For example, under RH8.0 it doesn't work anymore,
because things are not installed in $PREFIX/lib/site_perl but
$PREFIX/lib/perl5/site_perl...
Anyways, there is $Config{'installstyle'} that knows.
Following p
Randy Kobes wrote:
Hi,
Visual Studio (and I think some other compilers) like to
have variables declared up front. This diff
Thanks Randy, committed.
I still wish to find a compiler option to prevent this in first place. I've
gcc 3.2 and it happily accepts the definitions after the code seg
Philippe M. Chiasson wrote:
Just noticed that specifying PREFIX to perl Makefile.PL doesn't quite
work all the time. For example, under RH8.0 it doesn't work anymore,
because things are not installed in $PREFIX/lib/site_perl but
$PREFIX/lib/perl5/site_perl...
Anyways, there is $Config{'installsty
Doug MacEachern wrote:
On Thu, 27 Jun 2002, Stas Bekman wrote:
[posting here and not to httpd-test, since it's relevant only to mod_perl]
unless you have better ideas this patch makes it possible to start the
server with correct blib during 'make test', which otherwise is
completely bypassed
On Thu, 2003-01-23 at 12:10, Stas Bekman wrote:
> Randy Kobes wrote:
> > Hi,
> > Visual Studio (and I think some other compilers) like to
> > have variables declared up front. This diff
>
> Thanks Randy, committed.
>
> I still wish to find a compiler option to prevent this in first place. I'v
On Thu, 2003-01-23 at 12:36, Philippe M. Chiasson wrote:
> On Thu, 2003-01-23 at 12:10, Stas Bekman wrote:
> > Randy Kobes wrote:
> > > Hi,
> > > Visual Studio (and I think some other compilers) like to
> > > have variables declared up front. This diff
> >
> > Thanks Randy, committed.
> >
> >
Here's a patch for mod_perl 1's Makefile.PL that does
some things for Win32 -
- defines $PERL_DIRECTIVE_HANDLERS on Win32, for use with
Apache::ModuleConfig, when compiling with Visual Studio.
- defines $PERL_SECTIONS for Win32;
- uses Perl's touch(), rather than a system one.
Just for completeness, attached is a diff against the
src/modules/perl mod_perl 1.0 cvs directory which gets rid of
(all but one) warning on Win32. There's a few typecast
insertions, plus some avoiding declaring variables that won't be
used for Win32. One thing that I wasn't quite sure about the
po
Philippe M. Chiasson wrote:
On Thu, 2003-01-23 at 12:36, Philippe M. Chiasson wrote:
On Thu, 2003-01-23 at 12:10, Stas Bekman wrote:
Randy Kobes wrote:
Hi,
Visual Studio (and I think some other compilers) like to
have variables declared up front. This diff
Thanks Randy, committed.
I st
14 matches
Mail list logo
