httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: httpd-2.0 configure.in
Date Fri, 09 Mar 2001 15:01:14 GMT
On Fri, Mar 09, 2001 at 07:59:30AM -0600, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gstein@lyra.org>
> Sent: Friday, March 09, 2001 7:46 AM
>...
> > Now that you've done a ton of work in xml/expat, I'm going to propagate a
> > bunch of that work back to the main Expat repository (along with Ryan's
> > compiler warning patches). The ideal is for xml/expat to look just like the
> > standard Expat CVS. However, we may always end up with a different Windows
> > build (for example: you're only building static, but the official CVS needs
> > to build DLLs). I know that I can get the Unix side in sync between
> > httpd-2.0 and Expat's CVS.
> 
> I'm looking forward to it.  I'll be happy to patch expat.dsp this weekend,
> which I didn't use since we didn't need a .dll for win32.

Actually, we could use the .dll form on Windows. It is sharable, which
should avoid some of the problems we saw with expat-lite being built in and
exporting its symbols. The hope for Unix is to always build our expat as a
.so, thus allowing other modules (e.g. Perl's expat wrapper) to also bind
against it.

[ if .so's aren't available, then the person is creating a monolithic Apache
  anyways, so symbol conflicts shouldn't occur; there may be some wonky
  variations in here, but that's my initial thought ]

> The biggest issue was the versioning and conf file rewriting.  Do we need to
> do this at our level, or can that come with the version rather than three
> substs for the version indirected?
> 
> I ask since it would be much cleaner to just create the versioning in the
> release and checkout, rather than end users rewriting it.

At the Python Conference, I spoke with the current admin of the Expat
project (Fred Drake). Basically, he said "do what you think is best, but
just don't break it [and I trust you / know you wouldn't]."

So we can do whatever we think is best. Also, I told him "we [the ASF /
httpd group] have great Win32 talent, so we can fix up Expat's win32
issues." He was quite pleased :-) [ basically, he couldn't keep the .dsp
maintained properly and/or set it up "well" ]

The numbers originate in configure.in, and propagate into libtool and into
lib/expat.h. In the CVS copy, they would stash a generated copy of expat.h,
which allowed the Windows platform access to those values. In our bundled
Expat, we don't keep generated values, so they disappeared :-(

The right answer might be to put the "real" values into expat.h and stop
generating that file. configure.in can extract the values from expat.h and
feed them to libtool. Windows would just use expat.h.

The (CVS-Expat) release process would tweak the values in expat.h, rather
than values in configure.in.

Seem like a plan?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message