On 8/25/07, Ross Bamford <[EMAIL PROTECTED]> wrote: > 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.
I'm not sure it's any different than the current arrangement. We still have two packages. So for the end-user there is a dependency already. Or am I missing your point? > 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). Considering libxslt is a whole 6 files of code and maybe 10 files for tests, it certainly wouldn't get in the way, so to speak. Anyone see a reason we ought not to merge them? T. _______________________________________________ libxml-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/libxml-devel
