On Fri, 24 Aug 2007 23:39:36 +0100, TRANS <[EMAIL PROTECTED]> wrote: > On 8/23/07, Charlie Savage <[EMAIL PROTECTED]> wrote: >> > In the second case the version numbers can diverge. So it allows a >> > little more independence between the two libs. The downside is that >> > one has to keep track of which version of libxml to use for a >> > particular version of libxslt. Not a big deal, really, but there it is >> > nonetheless. Also, something to consider, for this last option, it >> > would be possible to move the libxslt lib over to it's own Rubyforge >> > project (which already exists actually). Maybe that's a better idea? >> >> I'd vote a separate project. > > Sean told me he was indifferent, but half-suggested that we might > merge the two libs completely. I'm not qualified enough to make that > call. But Charlie's makes at least one vote for the separate > project/repo. So unless any of you have anything else to add, I'm > leaning toward that approach. Let me know as soon as you can. I'd like > to get this taken care of over the weekend.
The only problem I can see with a separate project is that we're then introducing C dependencies between two totally separate ruby binding projects - this seems to me to be bad, but for no reason that I can put my finger on right now. Completely merging the two is interesting, and really only depends on how common it is to have libxml2 installed, but not libxslt. Although even if is quite common, extconf could check for libxslt, defining a HAVE_LIBXSLT or whatever. We can then selectively ignore the xslt stuff when compiling the c (making libxslt an optional dependency, obviously). -- Ross Bamford - [EMAIL PROTECTED] _______________________________________________ libxml-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/libxml-devel
