httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <gr...@alum.wpi.edu>
Subject Re: E: Win Build System
Date Fri, 24 Mar 2000 01:47:14 GMT
At 02:29 PM 03/23/2000 -0600, William A. Rowe, Jr. wrote:
> > From: Greg Marr [mailto:gregm@alum.wpi.edu]
> > 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?
>
>No, a single DSW with a list of the relationships of all of our
>existing projects is not an issue.  Overhauling the DSP's is more of
>an issue, and trashing makefile.win is the crux of my issues with this.

So, you haven't even looked at anything, then.  The ONLY changes I made to 
the DSPs were REMOVING some items from the linking options, and changing 
the locations of the output directories.

> > So why do we even have DSPs then?  Why not just write the .mak by
> > hand?  The only thing that the Makefile.win 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.
>
>No, I'm saying that we are not about to restrict design changes to a 
>specific IDE.  There are other IDEs to wrap VC.  There are other products 
>entirely.  (small slam, correct me if I'm wrong but) I'm guessing you 
>pretty much leave all the libraries in the default list of link 
>libraries.  What on earth would GDI32.DLL do for your command line 
>utility?  I'm all for stating _exactly_ what the program requires, and 
>_exactly_ how to include it.

Well, that's for a different discussion.  Overhauling the EXISTING DSPs 
that ALREADY do all the compilation is far beyond the scope of what I was 
proposing.  I agree, there are a lot of probably-unnecessary link flags in 
the DSPs, which have been around since July of 1997.

>This big point is anyone can read makefile.win today.  It does not require 
>the IDE.  Therefore every programmer, even on un*x, can read and comment 
>on it, and get a big picture of how we have done things in Win32.

Yeah, you get a really good picture of how we have done things in Win32 
from that file.

Before we continue this discussion, why don't you actually read the thing?

http://www.apache.org/websrc/cvsweb.cgi/apache-2.0/src/Makefile.win?rev=1.3

> > 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.
>
>EXCUSE me?  VC is a product independant of the DevStudio.  The IDE is a 
>wrapper to make the lives of poor coders far more efficient and 
>effective.  I use the InterDev features all the time for client's 
>websites.  I use the -integrated- debugger to diagnose VB .DLL issues.
>
>But it is a wrapper.  CL, MAKE and the rest of the command line family are 
>very effective at building projects, no IDE windows required.

Yes, but you can't get a .MAK from a .DSP without the IDE, AFAIK, and 
building Apache for Win32 has been controlled from the DSPs for almost 3 
years now.  I only added the following files when doing this:
Apache.dsw, ApacheInstall.dsp, and Install.mak.  ALL of the other files 
were already there, and only had minor changes.

>The point is reproducibility.  We have a VCVARS32.BAT and Platform SDK 
>SETENV.BAT courtisy of M$ for just this reason.  We cannot start 
>committing five daily changes to the dsp, just because five coders are 
>working on the project tripping options.  And regenerating the mak file 
>every time is not acceptable for this reason...

Well then, why don't you go ahead and build an entirely new make system for 
Win32 so you can avoid this.  Until then, you're stuck with this, whether 
my proposed changes are implemented or not.

>I need to see, when someone commits a patch, _precisely_ what changed. 
>Reading the diffs of .dsp and regenerated .mak files is a very, very 
>_ineffective_ use of my time.

So don't do it.

>Oh, precisely when did the ASF enthrone VC as the sole build tool?

According to the CVS logs, Sun Jul 20 12:31:09 1997 by ben
but then, there may be earlier instances that are no longer showing up.
http://www.apache.org/websrc/cvsweb.cgi/apache-1.3/src/ApacheCore.dsp

>This makes me think we should move all the .dsp/.dsw junk off (sorry, not 
>junk, but highly dependant on a specific, not-open source, not publicly 
>licensed tool) to a /src/build/tools/msvc folder, to isolate the means to 
>the project from the meat of the project.

In case you haven't noticed, most of the DSPs for the modules are already 
in a separate directory from the module source: src/os/Win32.

>Make files are (reasonably) generic, can be read by any programmer (even 
>Un*x guys when they need to figure out the big picture) and must be 
>adapted from tool to tool.  IDE data stores are too tangled up with the 
>specific structure of each IDE.

So then why have they been used for the Win32 builds for almost three years 
now?

>So, I applaud your efforts at making the entire list begin thinking about 
>this!  If someone on a xwindows project IDE sets up the working 
>environment, let's share it!  IDE's aren't bad.  They are simply too 
>individual to weight down the entire Apache code base.

Well, guess what, they've been weighing down the entire Apache code base 
since long before I showed up here.


Mime
View raw message