httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <>
Subject RE: Win Build System
Date Thu, 23 Mar 2000 16:58:20 GMT
At 11:25 AM 03/23/2000, William A. Rowe, Jr. wrote:
> > From: Greg Marr []
> > Sent: Thursday, March 23, 2000 9:49 AM
> >
> > >What problem are we fixing with these changes?
> >
> > The problem is the high startup cost for Windows developers who 
> use
> > the VC++ IDE and want to work on Apache (such as myself.)
> > 1) There is currently no workspace available for people who use 
> VC++
> > from the IDE as opposed to the command line.  Anyone who wishes to
> > build Apache from the IDE has to build their own workspace, and a
> > makefile DSP to wrap  The build warnings and errors
> > from this type of DSP do not have path information, which disable 
> the
> > features of the IDE that make getting to those warning/error
> > locations easy.
>Correct, but adding a dsw solves that

No, it doesn't.  It only solves part of it.

> > 2) When using from the IDE, the sub projects aren't
> > available for easy access.  They also aren't available for any of 
> the
> > advanced features of VC++ 6.0 such as IntelliSense, ClassView.
>Ok, but simply adding a dsw solves that.

Which of the changes are you objecting to?  Are you objecting to 
adding the DSPs, and setting up dependencies between them?  You 
already posted a DSW that did that, so that can't be it.  Are you 
objecting to the relocation of the object and executable files?  Are 
you objecting to the modification of the install method?

I separated out the changes into stages, so people can comment on 
what level of change they're comfortable with.

> > 3) The existing isn't exactly the easiest thing in 
> the
> > world to maintain.  The patches greatly reduce the amount of 
> makefile
> > code that has to be written by hand.  (It's practically nothing 
> now.)
>I strongly disagree.  I would rather trust a coder's changes than 

So why do we even have DSPs then?  Why not just write the .mak by 
hand?  The only thing that the does is chain to the 
.MAK/DSP files, and when installing, make the directories and copy 
the files.  I copied the logic from there for making the directories 
and copying some of the files.  I combined many of the rest of the 
copies into a single operation.  You trust MS's changes over a 
coder's for the entire build itself, but not for managing what builds 
are run in which order?  That seems backwards to me.

> > 4) There have been recent reports of problems with the %LONG% and
> > %SHORT% expansions in the makefile not being done, causing build
> > failures.
>*** Already corrected ***

Okay, so ignore that point.

> > 5) Configuring which modules are included in the build once 
> they're
> > in the workspace is a matter of checking or unchecking boxes in a
> > list.  If you don't want to use the IDE, you can also open 
> Apache.mak
> > and comment out the lines that build that module.
>I'm working up a slow, gradual overhaul of the Windows build 
>options.  I didn't look at what you did on this point, but we aren't 
>about to  'ditch' the command line build.

I'm not trying to ditch the command line build.  In fact, if you look 
at what I posted, I went to great lengths to preserve the command 
line build.  Last night I pretty much scrapped what I had and started 
over because the command line build wasn't working.

>When the trees are tagged and rolled, there will be no IDE.  Anyone 
>can reproduce what is about to be built and assure the end product 
>is good.

Unless you have VC++, the .mak files won't do you any good.  If you 
have VC++, you have the IDE, so I don't see how "there will be no 
IDE" makes any sense here.

Greg Marr
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"

View raw message