Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <494B0A61.5080208@rowe-clan.net>
Date: Thu, 18 Dec 2008 20:43:45 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.18 (X11/20081119)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [VOTE] Release Apache HTTP server 2.2.11
References: <493AA88D.6030908@apache.org> <4943C762.60205@apache.org>
 <303AB6A3-009D-428E-84B3-7ECE0BBEED62@jaguNET.com>
 <41CA780F40924E2CA8851C25B47D0616@bspc0>
 <43e40e000812170307k7a72727asa6f77eb13586b632@mail.gmail.com>
 <245358B217FA4932A6AF3B1B4FB39A42@bspc0> <494A8C4A.8040706@rowe-clan.net>
 <010801c9617b$ff4b81e0$fde285a0$@edu.cn>
In-Reply-To: <010801c9617b$ff4b81e0$fde285a0$@edu.cn>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

bing swen wrote:
> 
> So is it a good idea to maintain two sets of project files to cope with this problem: one for the old VS 5/6 .dsp files (no more x64 support), and one for VS 2005/08 .vcproj files (with direct x64 support)?

No, it's a horrid idea.

It's a good idea to drop to one cross-platform reference file as
apr has (config.layout), and spit out whatever the heck the user
wants (visual studio .dsw, .sln, eclipse, codewarrior etc etc.)

Right now windows users are treated to a gui perspective of httpd
(which I'll state firsthand is an amazingly better way to become
acquainted with the code base) while unix users stumble in makefile
land of ./configure --help.

But the number one problem at httpd builds has always been that the
.dsp falls out of sync with makefile.in and config.m4, while the
netware build is often not updated for half a year.  That's what
happens when we appeal to each special interest of their own unique
build system.

So my holiday project is to resolve apr for win32 from config.layout
etc.  (If Netware wasn't an orphaned platform, I'd even likely start
replacing their files too, but I'll let someone interested in orphans
start dealing with that).  Once successful, going to look at doing the
same over here.  And likely will stick with config.m4 files as best
as I can, since love them or hate them, they are what we are used to.