You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/02/25 21:56:54 UTC
Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
On 25 Feb 2001 wrowe@apache.org wrote:
> wrowe 01/02/25 12:53:42
>
> Modified: . Apache.dsw Makefile.win
> Log:
> Bring in the expat.lib into the static aprutil.lib win32 library.
> Fix up the build order that messed up command-line builds due to
> the recent dependency of apr-util on expat-lite.
this brings up an interesting point. Should expat-lite move out of httpd
and into apr-util? apr-util is useless without it, and httpd shouldn't
really need it anymore.
Ryan
Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
+1
I spent 20 minutes pondering the same thing - but knew your or greg would have
ideas, issues and solutions.
----- Original Message -----
From: <rb...@covalent.net>
To: <ne...@apache.org>
Cc: <ht...@apache.org>
Sent: Sunday, February 25, 2001 2:56 PM
Subject: Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
> On 25 Feb 2001 wrowe@apache.org wrote:
>
> > wrowe 01/02/25 12:53:42
> >
> > Modified: . Apache.dsw Makefile.win
> > Log:
> > Bring in the expat.lib into the static aprutil.lib win32 library.
> > Fix up the build order that messed up command-line builds due to
> > the recent dependency of apr-util on expat-lite.
>
> this brings up an interesting point. Should expat-lite move out of httpd
> and into apr-util? apr-util is useless without it, and httpd shouldn't
> really need it anymore.
>
> Ryan
>
>
Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sounds like a great solution. _Please_ preserve the expat/libexpat .dsp/.mak
files while you are moving things around, it will save me much trouble later on.
I had given up on their .dsp files, and please leave the 'official' xmltok
and xmlparse .dsp/.mak files in that directory. We _won't_ use them, but we
might as well leave their package mostly unscathed.
Bill
----- Original Message -----
From: <cl...@yahoo.com>
To: <ne...@apache.org>
Sent: Sunday, February 25, 2001 6:34 PM
Subject: Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
> On Sun, 25 Feb 2001 rbb@covalent.net wrote:
>
> > > 4) remove the --with-expat switch and add a copy of expat into apr-util/xml
> > > (and remove httpd-2.0/srclib/expat-lite)
> > >
> > > *) windows could just always use xml/expat/ (and the new one includes .dsp
> > > files and whatnot)
> > > *) autoconf'd systems would use the system expat or fall back to the bundled
> > > copy of expat 1.95
> > > *) by moving away from expat-lite, we can also use shared libs which helps
> > > the mod_perl conflict story
> > > *) switching to expat 1.95 also cleans up licensing: the old one was MPL
> > > 1.1, the new one is MIT/X
> > >
> > > Before putting a new copy of expat into apr-util/xml, I had wanted to run
> > > this by people first for thoughts.
> >
> > IMHO, this is a no-brainer, do it. :-)
>
> +1
>
> --Cliff
>
>
Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
Posted by cl...@yahoo.com.
On Sun, 25 Feb 2001 rbb@covalent.net wrote:
> > 4) remove the --with-expat switch and add a copy of expat into apr-util/xml
> > (and remove httpd-2.0/srclib/expat-lite)
> >
> > *) windows could just always use xml/expat/ (and the new one includes .dsp
> > files and whatnot)
> > *) autoconf'd systems would use the system expat or fall back to the bundled
> > copy of expat 1.95
> > *) by moving away from expat-lite, we can also use shared libs which helps
> > the mod_perl conflict story
> > *) switching to expat 1.95 also cleans up licensing: the old one was MPL
> > 1.1, the new one is MIT/X
> >
> > Before putting a new copy of expat into apr-util/xml, I had wanted to run
> > this by people first for thoughts.
>
> IMHO, this is a no-brainer, do it. :-)
+1
--Cliff
Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
Posted by rb...@covalent.net.
> Actually, apr-util doesn't depend on expat-lite. Apache just feeds a
> --with-expat switch to it to say "use *this* Expat for building".
>
> That was the shortest path towards a build for apr-util. Here are the four
> alternatives we have:
>
> 1) continue with the ../expat-lite thang
> 2) toss Expat from the build and require it be installed before building
> Apache
> 3) toss Expat and add configure magic to disable everything that depends on
> it (apr_xml and, in turn, mod_dav(_fs))
> 4) remove the --with-expat switch and add a copy of expat into apr-util/xml
> (and remove httpd-2.0/srclib/expat-lite)
>
> We're seeing that (1) is a bit troublesome for custom configs (like jimjag)
> and for Windows.
>
> (2) is a bitch. (3) is troublesome. (4) was my intended solution.
>
> The (4) solution is nice in another way: the bundled apr-util/xml/expat is
> only a *fallback*. If aprutil's configure finds expat already installed
> somewhere on the machine, then it will use it over the bundled copy. This is
> advantageous (we can pick up the system's shared lib of expat).
>
> Also, I'm not planning to simply shift expat-lite into apr-util/xml, but
> grab the latest copy. The current expat is autoconf'd and libtool'd. The
> aprutil autoconf script recognizes that, too :-)
>
>
> So... the situation would be:
>
> *) windows could just always use xml/expat/ (and the new one includes .dsp
> files and whatnot)
> *) autoconf'd systems would use the system expat or fall back to the bundled
> copy of expat 1.95
> *) by moving away from expat-lite, we can also use shared libs which helps
> the mod_perl conflict story
> *) switching to expat 1.95 also cleans up licensing: the old one was MPL
> 1.1, the new one is MIT/X
>
> Before putting a new copy of expat into apr-util/xml, I had wanted to run
> this by people first for thoughts.
IMHO, this is a no-brainer, do it. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 Apache.dsw Makefile.win
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 25, 2001 at 12:56:54PM -0800, rbb@covalent.net wrote:
> On 25 Feb 2001 wrowe@apache.org wrote:
>
> > wrowe 01/02/25 12:53:42
> >
> > Modified: . Apache.dsw Makefile.win
> > Log:
> > Bring in the expat.lib into the static aprutil.lib win32 library.
> > Fix up the build order that messed up command-line builds due to
> > the recent dependency of apr-util on expat-lite.
>
> this brings up an interesting point. Should expat-lite move out of httpd
> and into apr-util? apr-util is useless without it, and httpd shouldn't
> really need it anymore.
Actually, apr-util doesn't depend on expat-lite. Apache just feeds a
--with-expat switch to it to say "use *this* Expat for building".
That was the shortest path towards a build for apr-util. Here are the four
alternatives we have:
1) continue with the ../expat-lite thang
2) toss Expat from the build and require it be installed before building
Apache
3) toss Expat and add configure magic to disable everything that depends on
it (apr_xml and, in turn, mod_dav(_fs))
4) remove the --with-expat switch and add a copy of expat into apr-util/xml
(and remove httpd-2.0/srclib/expat-lite)
We're seeing that (1) is a bit troublesome for custom configs (like jimjag)
and for Windows.
(2) is a bitch. (3) is troublesome. (4) was my intended solution.
The (4) solution is nice in another way: the bundled apr-util/xml/expat is
only a *fallback*. If aprutil's configure finds expat already installed
somewhere on the machine, then it will use it over the bundled copy. This is
advantageous (we can pick up the system's shared lib of expat).
Also, I'm not planning to simply shift expat-lite into apr-util/xml, but
grab the latest copy. The current expat is autoconf'd and libtool'd. The
aprutil autoconf script recognizes that, too :-)
So... the situation would be:
*) windows could just always use xml/expat/ (and the new one includes .dsp
files and whatnot)
*) autoconf'd systems would use the system expat or fall back to the bundled
copy of expat 1.95
*) by moving away from expat-lite, we can also use shared libs which helps
the mod_perl conflict story
*) switching to expat 1.95 also cleans up licensing: the old one was MPL
1.1, the new one is MIT/X
Before putting a new copy of expat into apr-util/xml, I had wanted to run
this by people first for thoughts.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/