--On Friday, February 20, 2004 8:09 PM + Patrick Welche
<[EMAIL PROTECTED]> wrote:
Just an off-the-cuff remark: How does this tie in with say SASL
(old page at: http://asg.web.cmu.edu/sasl/) ?
(vision of mod_sasl, then plug in any old authentication method
into that)
SASL is more generic than
On Fri, Feb 20, 2004 at 01:12:59PM -0700, Brad Nicholes wrote:
> >The way I suspect Greg is heading is that you get a
> >./gen-build.py netware, which can be run on any platform to
> >produce the things you need to do the Netware build. So
> >this should be an improvement, since you don't have to
>The way I suspect Greg is heading is that you get a
>./gen-build.py netware, which can be run on any platform to
>produce the things you need to do the Netware build. So
>this should be an improvement, since you don't have to move
>files, build a tool, move it back, then build.
OK, now I underst
On Fri, Feb 13, 2004 at 06:28:34PM +0100, Axel Grossklaus wrote:
>
> i am currently working on mod_authn_dbi (part of the 2.1 Authentication
> Project http://mod-auth.sourceforge.net/) which uses the new
> authentication framework of apache 2.1. and was wondering if it
> was still possible to sugg
On Fri, Feb 20, 2004 at 01:59:28PM -0500, Jim Jagielski wrote:
>...
> No, I have no solutions, nor did I mean to imply that:
>
> o Such a solution is trivial
> o That the solution used was done with no
> thought of impact to developers.
Well, thought *was* applied, but to be honest,
On Fri, 2004-02-20 at 19:50, Brad Nicholes wrote:
>I am still confused as to what this all means. What do you all mean
> by "Platform". I keep reading these email messages and it sounds like
> "Platform" == "Linux". NetWare doesn't use buildconf but yet we still
> have to generate the files.
On Fri, Feb 20, 2004 at 11:50:55AM -0700, Brad Nicholes wrote:
>I am still confused as to what this all means. What do you all mean
> by "Platform". I keep reading these email messages and it sounds like
> "Platform" == "Linux".
The "Platform" will be NetWare. The gen-build script should be
On Fri, 2004-02-20 at 19:59, Jim Jagielski wrote:
> Greg Stein wrote:
> >
> > > I hate to chime in here, but I must agree. Things have certainly
> > > come a long way when the build/configure system tried to
> > > be as LCD (lowest common denominator) as possible.
> >
> > And it was a recursive m
Greg Stein wrote:
>
> > I hate to chime in here, but I must agree. Things have certainly
> > come a long way when the build/configure system tried to
> > be as LCD (lowest common denominator) as possible.
>
> And it was a recursive make solution which we're trying to fix. If you can
> come up wit
I am still confused as to what this all means. What do you all mean
by "Platform". I keep reading these email messages and it sounds like
"Platform" == "Linux". NetWare doesn't use buildconf but yet we still
have to generate the files. We also don't build directly on the NetWare
platform, we
On Fri, Feb 20, 2004 at 06:12:07PM +0100, Sander Striker wrote:
> > From: Greg Stein [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 20, 2004 6:00 PM
>
> > And the notion of "well, now it doesn't build on my platform" is quite
> > suspect. The output of the process (run at buildconf time) is
On Fri, Feb 20, 2004 at 01:10:06PM -0500, Jim Jagielski wrote:
> Ben Laurie wrote:
> >
> > Or even platforms you have heard of: within hours of this change I had
> > complaints from people who couldn't build snapshots in order to try out
> > mod_log_forensic...
>
> I hate to chime in here, but
Roy T. Fielding wrote:
However I completely disagree that Python (or Perl or PHP) is
a good choice for use in build systems.
As part of the configure process, I would agree with you, but as part of
buildconf, I disagree--not everyone needs to run buildconf--only
developers, and if you're
Ben Laurie wrote:
>
> Or even platforms you have heard of: within hours of this change I had
> complaints from people who couldn't build snapshots in order to try out
> mod_log_forensic...
>
I hate to chime in here, but I must agree. Things have certainly
come a long way when the build/configu
[EMAIL PROTECTED] wrote:
I like the idea of being able to identify which arbitrary module is the
handler and what it thinks the current state of the request is.
Yes it would be great to be able to find out things like:
request 1023 is in fixups mod_dir
request 657 is in output filter mod_includes
> From: Greg Stein [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 20, 2004 6:00 PM
> And the notion of "well, now it doesn't build on my platform" is quite
> suspect. The output of the process (run at buildconf time) is
> build-outputs.mk. Just copy that from *anywhere* to your target platform
On Fri, Feb 20, 2004 at 02:17:32AM -0700, Paul Querna wrote:
>
> > httpd is still just as "buildable" on such platforms regardless of
> > gen-build.py: from the release tarballs. Building from a CVS checkout
> > cannot be done without extra tools, but that has always been true in
> > 2.0: you nee
Ben Laurie wrote:
Jeff Trawick wrote:
Jim Jagielski wrote:
I'd like to float the idea of releasing 1.3.30 "soonish".
one question: who would support putting the 1.3 versions of
mod_backtrace and mod_whatkilledus in experimental?
+1.
+1
Greg
On Fri, 20 Feb 2004, Patrick Welche wrote:
> On Fri, Feb 20, 2004 at 11:23:02AM +0100, Sascha Schumann wrote:
> > A shell script generating build-exports.mk is attached.
> >
> > The implementation lacks cyclic reference detection (some
> > header files point to each other). This can b
Roy T. Fielding wrote:
However I completely disagree that Python (or Perl or PHP) is
a good choice for use in build systems.
As part of the configure process, I would agree with you, but as part of
buildconf, I disagree--not everyone needs to run buildconf--only
developers, and if you're
On Fri, Feb 20, 2004 at 11:23:02AM +0100, Sascha Schumann wrote:
> A shell script generating build-exports.mk is attached.
>
> The implementation lacks cyclic reference detection (some
> header files point to each other). This can be resolved by
> splitting the 2-3 header files th
> > autoconf does not use perl.
>
> It has done since 2.50 AFAIK: from the README in 2.59:
Fortunately, one can choose not to use the horrible autoconf
2.5x. The sane versions up to 2.13 don't require perl for
buildconf'ing APR or httpd.
- Sascha
On Fri, Feb 20, 2004 at 11:27:29AM +0100, Sascha Schumann wrote:
> Please get your facts straight.
>
> > > httpd is still just as "buildable" on such platforms regardless of
> > > gen-build.py: from the release tarballs. Building from a CVS checkout
> > > cannot be done without extra tools, b
Please get your facts straight.
> > httpd is still just as "buildable" on such platforms regardless of
> > gen-build.py: from the release tarballs. Building from a CVS checkout
> > cannot be done without extra tools, but that has always been true in
> > 2.0: you need libtool and autoconf (not
A shell script generating build-exports.mk is attached.
The implementation lacks cyclic reference detection (some
header files point to each other). This can be resolved by
splitting the 2-3 header files though.
- Sascha
gen-build.sh
Description: Bourne shell script
atom
> httpd is still just as "buildable" on such platforms regardless of
> gen-build.py: from the release tarballs. Building from a CVS checkout
> cannot be done without extra tools, but that has always been true in
> 2.0: you need libtool and autoconf (not to mention the CVS client).
> Hell, autoco
On Thu, Feb 19, 2004 at 05:55:13PM -0800, Roy T. Fielding wrote:
> >>However I completely disagree that Python (or Perl or PHP) is
> >>a good choice for use in build systems.
> >
> >As part of the configure process, I would agree with you, but as part
> >of
> >buildconf, I disagree--not ev
27 matches
Mail list logo
