httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: cvs commit: apache-1.3/src/modules/standard mod_info.c
Date Wed, 10 May 2000 02:57:14 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Tuesday, May 09, 2000 6:42 PM
> 
> On Tue, 9 May 2000, William A. Rowe, Jr. wrote:
> >...
> > I have the changes for the 2.0 style build *completed* 
> (this time around
> > it was just two hours to get them right.)
> > 
> > I want to ask the Win32 folks for their opinion...  
> 
> Affects us non-Win32 people, too. I'd hate to say "I work 
> with Apache" and
> have people go "THAT piece of crap?!" "Oh, you mean the Win32 port."

Agreed... let me rephrase as 'I want to ask those of us who give 
2 cents about the Win32 port' :-)

> Despite that...
> 
> > Q1)  Do we move the -new- build structure to Apache-1.3? 
> 
> -0
> 
> I say that if 1.3 works, then don't fix it. If there is a *bug*, then
> great.

I have a simple reason - raid.  I'm getting a lot more problems licked
with that structure.  Second, I want 1.3.x users to become familiar
with what they will face with 2.0.  If we don't like this solution for
2.0, then we will change it.  I'm hearing very few complaints.

My own last reason is that Apache should build, without crud filling
up the drive.  If they are a programmer, and want "Browser Source Databases"
and other drivel (I actually do use them), then -they-know-how-to-friggin-
-flip-the-option-on-!!!  If they are just an admin building in a module,
why on earth are we asking for 40MB to compile apache!?!

So eliminating precompiled headers and browser files will go forward.
But I'd like just -one- make file for all win builds, that would be
makefile.win, and I construct it with the flags to turn off recursive
project compilation.  We know what we are building, in what order, and
don't want to do so in a loop.  And with that, adding the Apache.dsw
workspace view is a no-brainer.

These changes mean all the mak files are about to be updated, which
lead to a seperate question, before I assaulted the cvs-commit list...

> > Q2)  Do we dump the .mak files?
> 
> Are they breaking things?
> 
> If you dump them, then you could upset a number of processes 
> that people
> have in place to deal with the .mak files.
> 
> -0

So we are still at 0.  It's not happening unless I get a rousing
cry of 'Stop wasting the cvs space and filling up our mail with
.mak file commits!!!'  So far, assume they stay.
 
> > BTW - did anyone else notice that xmlparse compilation died 
> without xmltok?  
> > Are we using these?  If we are, I'll move my changes to 
> 2.0.  If not, I will 
> > remove them from the makefile.[nt|win]
> 
> Eh? In which tree? 1.3 or 2.0? And under the Win32 build, I presume?

The 1.3.13-dev Win32 NT build, of course.

> (feel free to fix things, but I can also assume 
> responsibility to ensure
>  that the XML stuff builds for our ports and both trees...)

Ahem... it doesn't.  That is, not on 2.0 right now.  Never did.
I'd be happy to add it, if we use it.  On 2.0, we don't.  That
doesn't mean I object to providing it (working, no less) for
3rd party modules.

> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 

Mime
View raw message