You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/12/03 10:17:04 UTC
Re: Directions for Win32 binary httpd
Ok, I've come to a conclusion; for the coming release, only msvcrt.dll
builds under Visual C++ 6.0 make sense as our binary distribution.
I'm not suggesting we dismiss the potential win of supporting our Studio
2005 compiler users(!) But let's quickly compare...
. binary users generally aren't building modules, they need to plug into
widely distributed binary components.
. source users generally can build anything from source, if they need to.
If they want to interface several components, they can build our source
tarball with any compiler they like, including the 1 year free license
of Studio 2005.
. it's pretty trivial to build/install httpd with one of several pretty
minimal unix toolchains available.
It seems that most of the communites are still in VC 6. Remember the key
reason we keep using it, MS dropped support for exporting makefiles. With
no makefiles, you are roped into supporting only version x or newer Studio
products. With .dsp/.dsw solutions, we can export makefiles on the old
reliable VC 6, and users can load/convert these into Studio 2000/03/05.
So I'll move ahead with all the msi tweaks required for our changed files,
and we can reevaluate the state of things 6 mos or a year from now when we
are almost ready to ship Apache X :)
That's my conclusion, I'm still more than happy to hear out dissenting
opinions. Speak up quick, though, planning to have a package up in /dev/dist
by Sunday night for review, and push it out sometime early next week.
Bill
Re: Directions for Win32 binary httpd
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Olaf van der Spek wrote:
> On 12/3/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>>It seems that most of the communites are still in VC 6. Remember the key
>>reason we keep using it, MS dropped support for exporting makefiles. With
>>no makefiles, you are roped into supporting only version x or newer Studio
>>products. With .dsp/.dsw solutions, we can export makefiles on the old
>>reliable VC 6, and users can load/convert these into Studio 2000/03/05.
>
> So why not distribute the VC6 dsp/dsw files but (officially) build
> with VS05 yourself?
Because, as noted, it's not compatible with binaries precompiled for most
languages that users would like to load into the running server, chief
amoung them being perl. (The PHP module is far less invasive, and generally
follows the portability rules I set forth in another note, w.r.t. not handing
off clib resources from httpd to modphp and back.)
Bill
Re: Directions for Win32 binary httpd
Posted by Olaf van der Spek <ol...@gmail.com>.
On 12/3/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> It seems that most of the communites are still in VC 6. Remember the key
> reason we keep using it, MS dropped support for exporting makefiles. With
> no makefiles, you are roped into supporting only version x or newer Studio
> products. With .dsp/.dsw solutions, we can export makefiles on the old
> reliable VC 6, and users can load/convert these into Studio 2000/03/05.
So why not distribute the VC6 dsp/dsw files but (officially) build
with VS05 yourself?
Re: Directions for Win32 binary httpd
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Francis ANDRE wrote:
>
> Thanks Bill... but I have noticed this first dependency since APR IS
> NOT delivered with httpd (at least with CVS). One have to
> checkout ap, apr-util and apr-iconv in the httpd/srclib directory...
Sure, and this is just fine with the developers. APR actually is not THIS
project, although it's an Apache Software Foundation project developed at
(dev@apr.apache.org). But we deliver all these things you mention with
the win32 src zipfile, and all but apr-iconv in the unix tarball.
> Anyway, I give up with ant as a building tool since no one understand
> that autoconf/configure is only Linux,BSD or whatever Unix dependent...
> None are using autoconf which needs m4 which needs .....
Apples and oranges. Ant doesn't solve this problem, it's merely a way
(like make/gmake/nmake etc) to compile files.
*Should* we replace autoconf (m4, libtool, et al)? Sure :) These tools
are broken regularly (well, m4's pretty rock stable) from release to
release, so we have a lot of trouble predicting what will work on older
box X, even on *nix'es and *nix-alikes. Right now we have customized
solutions, or no solutions, on a per-platform basis.
Since APR must be solved (list address above) before httpd can be solved,
I'll treat further posts about ./configure, here at dev@httpd, as nothing
more than trolling. If you care to join the discussion at dev@apr, about
replacing unix-script configure or make files, then by all means join us.
Bill
Re: Directions for Win32 binary httpd
Posted by Francis ANDRE <fr...@easynet.fr>.
> His further dismissal of beginning at APR leads me to suspect that he's
> never actually built httpd, or in the process, never noted that APR is
> the first, most fundemental dependency. If APR is not built using ant,
> all further discussion on this list is rather pointless, no?
Thanks Bill... but I have noticed this first dependency since APR IS NOT
delivered with httpd (at least with CVS). One have to
checkout ap, apr-util and apr-iconv in the httpd/srclib directory...
Anyway, I give up with ant as a building tool since no one understand that
autoconf/configure is only Linux,BSD or whatever Unix dependent...
How are you dealing with system/compiler dependencies on WXP, OS/400, VMS,
0S/390, Bull GCOS and any non Unix OS???
If you want a building process based on platform/compiler/OS dependencies
without Java/Ant and without autoconf, look also at www.boost.org, they are
doing quite well!!
None are using autoconf which needs m4 which needs .....
Francis
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Friday, December 09, 2005 2:06 AM
Subject: Re: Directions for Win32 binary httpd
> Nick Kew wrote:
>>
>> I really don't like the idea of having to install ant just to build
>> apache.
>> It's a major new dependency, yet adds nothing to the server.
>
> We have too many dependencies, at least this -one- would be ASF software.
> I wholeheartedly support the concept, but don't believe this is actually
> a viable option at this point.
>
> Moreover, Francis' comments reflect a lack of comprehension with respect
> to the chore of determining platform specific details that (at the moment)
> require us to use autoconf, or some similar detection/test compilation
> feature. Ant is not prepared to handle these issues, and autoconf's
> results aren't well integrated to serve ant.
>
> His further dismissal of beginning at APR leads me to suspect that he's
> never actually built httpd, or in the process, never noted that APR is
> the first, most fundemental dependency. If APR is not built using ant,
> all further discussion on this list is rather pointless, no?
>
> Bill
>
>
Re: Directions for Win32 binary httpd
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
>
> I really don't like the idea of having to install ant just to build apache.
> It's a major new dependency, yet adds nothing to the server.
We have too many dependencies, at least this -one- would be ASF software.
I wholeheartedly support the concept, but don't believe this is actually
a viable option at this point.
Moreover, Francis' comments reflect a lack of comprehension with respect
to the chore of determining platform specific details that (at the moment)
require us to use autoconf, or some similar detection/test compilation
feature. Ant is not prepared to handle these issues, and autoconf's
results aren't well integrated to serve ant.
His further dismissal of beginning at APR leads me to suspect that he's
never actually built httpd, or in the process, never noted that APR is
the first, most fundemental dependency. If APR is not built using ant,
all further discussion on this list is rather pointless, no?
Bill
Re: Directions for Win32 binary httpd
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/08/2005 11:20 PM, Garrett Rooney wrote:
> On 12/8/05, Ruediger Pluem <rp...@apache.org> wrote:
[..cut..]
>
> It's not just the "outer rim", most BSD systems don't have Java
> installed, and I'd hardly consider them fringe platforms.
Sorry for this. I never intended to put BSD systems to the "outer rim". I guess I work too much
with java and thus with the platforms that have it installed normally :-).
But this makes my argument against using Ant even stronger.
Regards
Rüdiger
Re: Directions for Win32 binary httpd
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 12/8/05, Ruediger Pluem <rp...@apache.org> wrote:
> Furthermore you need a platform with a recent JDK. Of course our main platforms should provide
> this, but I think many of the platforms on the outer rim do not have this.
> Converting the build system to Ant would cancel support for those platforms.
It's not just the "outer rim", most BSD systems don't have Java
installed, and I'd hardly consider them fringe platforms.
-garrett
Re: Directions for Win32 binary httpd
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/08/2005 06:57 PM, Nick Kew wrote:
> On Thursday 08 December 2005 17:07, Francis ANDRE wrote:
>
[..cut..]
>
> I really don't like the idea of having to install ant just to build apache.
> It's a major new dependency, yet adds nothing to the server.
Also my opinion. Ant is a great tool for many things, but not for this as
much of the work that needs to be done during the build process is
detecting platform specific things.
We already have a working build system that is based on standard tools and
I see no real gain in changing the build system again.
Furthermore you need a platform with a recent JDK. Of course our main platforms should provide
this, but I think many of the platforms on the outer rim do not have this.
Converting the build system to Ant would cancel support for those platforms.
Regards
Rüdiger
Re: Directions for Win32 binary httpd
Posted by Nick Kew <ni...@webthing.com>.
On Thursday 08 December 2005 17:07, Francis ANDRE wrote:
> IMHO, ant should not be used to generate the configure and makefile
> scripts; Instead the building process must avoid all these specific Unix
> tools like autoconf/configure. As a example of a great usage of ant for
> building a product, have a look to the directory in the Apache axis project
> : ws-axis/c/build.
I really don't like the idea of having to install ant just to build apache.
It's a major new dependency, yet adds nothing to the server.
Or am I missing something?
--
Nick Kew
Re: Directions for Win32 binary httpd
Posted by Paul Querna <ch...@force-elite.com>.
Francis ANDRE wrote:
> IMHO, ant should not be used to generate the configure and makefile
> scripts;
> Instead the building process must avoid all these specific Unix tools
> like autoconf/configure. As a example of a great usage of ant for
> building a
> product, have a look to the directory in the Apache axis project :
> ws-axis/c/build.
>
> It is the build directory for the Apache Axis C version targeting the
> major platforms as Linux, OS/400 HP-UX, OS/390 and so on.
>
> I am using a similar approach for a tool targeting WXP, Linux, OS/390
> and it
> works as expected: only one build infrastructure for all platforms.
Sounds great. Send Patches.
I personally also like SCons[1], which is in Python, and has a similar
goal to Ant.
-Paul
[1] http://www.scons.org/
Re: Directions for Win32 binary httpd
Posted by Francis ANDRE <fr...@easynet.fr>.
IMHO, ant should not be used to generate the configure and makefile scripts;
Instead the building process must avoid all these specific Unix tools
like autoconf/configure. As a example of a great usage of ant for building a
product, have a look to the directory in the Apache axis project :
ws-axis/c/build.
It is the build directory for the Apache Axis C version targeting the
major platforms as Linux, OS/400 HP-UX, OS/390 and so on.
I am using a similar approach for a tool targeting WXP, Linux, OS/390 and it
works as expected: only one build infrastructure for all platforms.
Regards
Francis
----- Original Message -----
From: "Graham Leggett" <mi...@sharp.fm>
To: <de...@httpd.apache.org>
Sent: Thursday, December 08, 2005 3:28 PM
Subject: Re: Directions for Win32 binary httpd
> Francis ANDRE wrote:
>
>> I do not address APR, but httpd. So even if APR seems to need make (while
>> I am not really convince that ant cannot makes the job)., ant could be
>> use for the httpd build process.
>
> The biggest body of work that needs to be done during the build is handled
> in the ./configure script. The ./configure script (built by autoconf) is
> designed already to handle the different types of make out there.
>
> Changing from make to ant would involve teaching autoconf to create
> ./configure to make ant scripts instead of Makefiles, and that's just
> doing the same thing just using a different program, it buys nothing.
>
> If however you extended ant so that it could do the job of
> autoconf/configure, then you would be onto something. But only on
> platforms that supported Java, of course.
>
> Regards,
> Graham
> --
>
>
>
Re: Directions for Win32 binary httpd
Posted by Graham Leggett <mi...@sharp.fm>.
Francis ANDRE wrote:
> I do not address APR, but httpd. So even if APR seems to need make
> (while I am not really convince that ant cannot makes the job)., ant
> could be use for the httpd build process.
The biggest body of work that needs to be done during the build is
handled in the ./configure script. The ./configure script (built by
autoconf) is designed already to handle the different types of make out
there.
Changing from make to ant would involve teaching autoconf to create
./configure to make ant scripts instead of Makefiles, and that's just
doing the same thing just using a different program, it buys nothing.
If however you extended ant so that it could do the job of
autoconf/configure, then you would be onto something. But only on
platforms that supported Java, of course.
Regards,
Graham
--
Re: Directions for Win32 binary httpd
Posted by Francis ANDRE <fr...@easynet.fr>.
I do not address APR, but httpd. So even if APR seems to need make (while I
am not really convince that ant cannot makes the job)., ant could be use for
the httpd build process.
Francis
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Thursday, December 08, 2005 11:59 AM
Subject: Re: Directions for Win32 binary httpd
> Francis ANDRE wrote:
>> Why don't you plan to use ant for the building process instead of
>> namke/make. The major avantage of using ant would be to get a coherent,
>> unique process for all majors platforms like WXP, Linux, Unix, OS/400,
>> OS/390
>
> Excellent suggestion! Why don't you propose a patch to the APR project
> to build APR (a required component) using ant as an alternative to make?
>
> Bill
>
>
Re: Directions for Win32 binary httpd
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Francis ANDRE wrote:
> Why don't you plan to use ant for the building process instead of
> namke/make. The major avantage of using ant would be to get a coherent,
> unique process for all majors platforms like WXP, Linux, Unix, OS/400,
> OS/390
Excellent suggestion! Why don't you propose a patch to the APR project
to build APR (a required component) using ant as an alternative to make?
Bill
Re: Directions for Win32 binary httpd
Posted by Graham Leggett <mi...@sharp.fm>.
Francis ANDRE wrote:
> Why don't you plan to use ant for the building process instead of
> namke/make. The major avantage of using ant would be to get a coherent,
> unique process for all majors platforms like WXP, Linux, Unix, OS/400,
> OS/390
There is still a significant amount of work involved in determining what
features/libraries/headers are available on a specific platform, a
problem ant doesn't solve for us.
Regards,
Graham
--
Re: Directions for Win32 binary httpd
Posted by Francis ANDRE <fr...@easynet.fr>.
Why don't you plan to use ant for the building process instead of
namke/make. The major avantage of using ant would be to get a coherent,
unique process for all majors platforms like WXP, Linux, Unix, OS/400,
OS/390
FA
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Saturday, December 03, 2005 7:31 PM
Subject: Re: Directions for Win32 binary httpd
> Steffen wrote:
>>> From a build standpoint I agree.
>>
>> But VC++ 2005 has improvements in Performance, MemoryManagement etc.
>> The optimizer seems to improve the performance quite significantly.
>>
>> Contrary to what Microsoft would like, you can built the server with the
>> needed DLLs statically so there is nothing to ship and nothing to
>> install.
>> The Sambar Server( www.sambar.com ) uses this approach.
>
> Steffan, you aren't considering the structure of httpd(!) Loading three
> dozen modules and several libraries, each with embedded Clib functions is
> quite sub-optimal ;-) For a monolithic program, I agree with your
> assessment.
>
> Of course, feel free to build under VC 2005 (freely for the next year!).
> We are talking about maximum flexibility for distribution purposes, only.
>
> Bill
>
>
Re: Directions for Win32 binary httpd
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
>> From a build standpoint I agree.
>
> But VC++ 2005 has improvements in Performance, MemoryManagement etc.
> The optimizer seems to improve the performance quite significantly.
>
> Contrary to what Microsoft would like, you can built the server with the
> needed DLLs statically so there is nothing to ship and nothing to install.
> The Sambar Server( www.sambar.com ) uses this approach.
Steffan, you aren't considering the structure of httpd(!) Loading three
dozen modules and several libraries, each with embedded Clib functions is
quite sub-optimal ;-) For a monolithic program, I agree with your assessment.
Of course, feel free to build under VC 2005 (freely for the next year!).
We are talking about maximum flexibility for distribution purposes, only.
Bill
Re: Directions for Win32 binary httpd
Posted by Steffen <in...@apachelounge.com>.
>From a build standpoint I agree.
But VC++ 2005 has improvements in Performance, MemoryManagement etc.
The optimizer seems to improve the performance quite significantly.
Contrary to what Microsoft would like, you can built the server with the
needed DLLs statically so there is nothing to ship and nothing to install.
The Sambar Server( www.sambar.com ) uses this approach.
Steffen
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Saturday, December 03, 2005 10:17 AM
Subject: Re: Directions for Win32 binary httpd
> Ok, I've come to a conclusion; for the coming release, only msvcrt.dll
> builds under Visual C++ 6.0 make sense as our binary distribution.
>
> I'm not suggesting we dismiss the potential win of supporting our Studio
> 2005 compiler users(!) But let's quickly compare...
>
> . binary users generally aren't building modules, they need to plug into
> widely distributed binary components.
>
> . source users generally can build anything from source, if they need to.
> If they want to interface several components, they can build our source
> tarball with any compiler they like, including the 1 year free license
> of Studio 2005.
>
> . it's pretty trivial to build/install httpd with one of several pretty
> minimal unix toolchains available.
>
> It seems that most of the communites are still in VC 6. Remember the key
> reason we keep using it, MS dropped support for exporting makefiles. With
> no makefiles, you are roped into supporting only version x or newer Studio
> products. With .dsp/.dsw solutions, we can export makefiles on the old
> reliable VC 6, and users can load/convert these into Studio 2000/03/05.
>
> So I'll move ahead with all the msi tweaks required for our changed files,
> and we can reevaluate the state of things 6 mos or a year from now when we
> are almost ready to ship Apache X :)
>
> That's my conclusion, I'm still more than happy to hear out dissenting
> opinions. Speak up quick, though, planning to have a package up in
> /dev/dist
> by Sunday night for review, and push it out sometime early next week.
>
> Bill
>
>