Kyle a écrit : > Julien PUYDT wrote: >> Kyle a écrit : >>> Of course, it would be much nicer is if libxml++ didn't have such a >>> heavy dependency on glibmm just for ustring's. >> Is libxml++ that interesting when compared to directly using libxml2 ? [...] > After a quick glance through the libxml2 api, it certainly seems doable > to switch to libxml2 directly. Though considering all the places that > libxml++ is used in the code, it would not be trivial. Throughout the > code xml objects are passed around, to remove these objects and replace > them with C code would be a pain. See the LoadXml functions in the > weapons or objects for examples of this.
I don't think replacing the C++ objects by C code is that difficult. In the example you point, those are just opaque objects, so any pointer object would do. The problem I see rather is that the libxml++ wrappers may do several things at a time (a quick glance through their DOM parser shows that they manipulate both a libxml context and a libxml doc), and unless replicating this logic, there may be some code refactoring. > Of course, another possible alternative is to embed the ustring class > itself into libxml++, and distribute our own version of that / ask the > maintainers to do this too. I suspect that this won't fly though. From the looks of it, glibmm, sigc and glib dependencies come from this, so using libxml++ does have a rather important cost. I'd be more in favor of replacing libxml++ instead of integrating glibmm::ustring Maybe the original developers could explain why they picked libxml++. Anyway, I'm less positive about the replacement being that easy. This whole topic sounds contrary to the current goal of fixing bugs for the current release, but like the curl dependency, it is worth inspecting for the release after that. Best regards, Kurosu _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
