From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Friday, March 09, 2001 9:01 AM
> On Fri, Mar 09, 2001 at 07:59:30AM -0600, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <[EMAIL PROTECTED]>
> > 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 problem is backwards on Win32. Monoliths see the .lib file objects, and may
have conflicts. The libdavutil.dll doesn't export a single expat symbol, so the
dynamic build of apr-util is very safe from conflicts.
> > 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?
That's about as easy as it gets. My #ifdef protection is probably right, though,
in case you want to build a test version only tweaking XML_MICRO_VERSION.
Bill
