Subject: Re: minimizing forks (was Re: commit -- removed unused directory in expat)
From: Thomas Briggs (tom@sane.com)
Date: Mon Feb 05 2001 - 12:59:14 CST
I wanna throw in a couple thoughts here:
It seems like the cool thing to do lately is check for the presence of a
system-wide, shared version if it exists, which isn't necessarily a bad
idea. If it isn't present, however, we seem to be moving towards a reliance
on "./configure; make" to build the necessary libs if shared versions don't
exist. That simply won't work on Win32; someone (apparently me) has to
write abi-style build systems for psiconv as well as expat before Win32 will
build from the command line again (and I don't see that happening any time
soon).
So I guess my point is that we will never escape the Makefile.abi type
build system, so we may as well take advantage of it.
-Tom
----- Original Message -----
From: "Paul Rohr" <paul@abisource.com>
To: "Sam TH" <sam@uchicago.edu>
Cc: "AbiWord Dev" <abiword-dev@abisource.com>
Sent: Monday, February 05, 2001 1:47 PM
Subject: minimizing forks (was Re: commit -- removed unused directory in
expat)
> At 11:23 PM 2/2/01 -0600, Sam TH wrote:
> >Ok, the situation with expat is kind of strange. (I've spend a good
> >bit of time over the last 24 hours hacking expat.) Their CVS tree
> >includes about 4 different directories with sample program. It should
> >be noted that none of them actually built properly (although that was
> >easy to fix). Only one of those programs (xmlwf) was distributed with
> >1.95.1, the version currently in our tree.
>
> Sam,
>
> I'm not familiar with more recent expat source drops, so I'll defer to
your
> knowledge there.
>
> My point was pretty simple. We use a ton of other people's code in
AbiWord.
> There are three ways to do so:
>
> A. use unmodified sources
> --------------------------
> Ideally, we'd be able to feed enough changes back upstream, so that we
could
> build what we need from totally unmodified copies of the maintainer's
> library.
>
> B. minimal additive forks
> --------------------------
> We've fallen into the practice of maintaining a very minor fork of these
> libraries, mainly to add a Makefile.abi for the convenience of our XP
build
> system. It looks like Hub's in the process of adding Makefile.mpws for a
> similar reason.
>
> As forks go, this is pretty benign, because everything from the original
> maintainer is still there and ready to use. We've just augmented it a
bit.
>
> C. more invasive forks
> -----------------------
> Yes, there are sections of the "official" expat sourcedrop that we don't
> need or use. (The same is true of wv.) However, it seems like a more
> invasive fork to delete them from the drops we publish. In short, we'd be
> distributing expat-- instead of expat.
>
> Maybe it's just me, but this feels a lot ruder.
>
> bottom line
> -----------
> I have a slight preference for A over B, but making that move sounds like
> a ton of work. I have a much stronger preference for B over C, in part
> because it seems like so much less work.
>
> >I have to say that I find
> >it extremely unlikely that anyone would come looking to our version of
> >expat so that they could build a tiny application, distributed to
> >demonstrate how to use expat, which canonicalizes XML.
>
> This feels like a red herring. The minimum expectation anyone should have
> when they download a copy of the expat sources is that it has all of expat
> in it.
>
> If they get a copy from us which has more, that's better.
>
> If they get a copy from us which has less, that's worse.
>
> >However, if
> >you continue to object, I'll probably put it back in. I won't put in
> >the other stuff in expat cvs that's not in our tree, though.
>
> Hmm. I'm not sure what to advise you on here. I've been assuming that
the
> only work needed to upgrade our copy of expat (or any other mirrored
> library we require) to a newer upstream version was roughly as follows:
>
> 1. identify what our diffs to the last baseline were
> 2. cvs import all of the new version
> 3. apply the patch from #1
> 4. update Makefile.abi to build any new files
> 5. ignore any unused "official" sources in our distro (but keep them)
>
> Our only difference of opinion here is how to handle #5, right?
>
> Paul,
> who doesn't mean to be cranky
>
>
This archive was generated by hypermail 2b25 : Mon Feb 05 2001 - 12:52:07 CST