GNOME Bugzilla – Bug 320197
allow building libxml++ without glibmm
Last modified: 2020-11-11 15:31:17 UTC
As discussed on libxml++ mailing list, here is a patch which allows to pass --without-ustring (or, for Win32 platforms not using configure, specify -DLIBXMLPP_USE_STD_STRING) to build libxml++ without glibmm. The patch adds new files libxml++/xmlstring.h and libxml++/config.h. The latter may be useful for other compile-time options as well. It updates the build system (but not configure nor Makefile.in, only configure.in and Makefile.am to avoid problems with diffs to generated files), the sources, examples and the docs. It was tested under a) Linux 2.6 both with glibmm installed and without it b) Darwin without glibmm c) Win32 using MSVC 7.1
Created attachment 54059 [details] [review] patch to allow building without glibmm dependency Patch against latest cvs HEAD, please apply using "patch -p1".
I really don't like typedefing std::string to Glib::ustring. I don't want to deal with the confusion when a Glib::ustring does not seem to handle UTF-8. The non-API-changing alternative would seem to need lots of #ifdefs. I wouldn't be happy about maintaining that. Maybe it would be OK for this just to exist as a patch?
I don't like much the typedef either. However I guess if it's well documented (for example, print a BIG warning at configure, in the header file, as well as an entry in a FAQ and/or the manual), it could be acceptable. What leads me to that idea is that, apparently, a lot of people would use it. And if this makes libxml++ more usefull, why not. This is not a decision, just a though before taking one (after may be another vote on the list ?).
I should repeat here that I'd like a patch for glibmm to split glibmm up (in a future parallel-installed ABI-breaking version) so that the dependency is not so large.
No, another vote isn't necessary. Feel free to commit this Christophe. I have enough reservations about the confusion it could cause that I don't want to perform that act myself. Please do make it clear in the configure warning/suggestion that distros should not use it.
I would really like the official libxml++ to support this. However, I got this error after applying the patch given: ./configure: line 19912: syntax error near unexpected token `5.6.0' ./configure: line 19912: ` GLIBMM_CHECK_PERL(5.6.0)' gmake: *** [config.status] Error 2 It was trying to run configure again for some reason when I did "make" after I already did "./configure --without-ustring" sucesssfully. It breaks when I do "make", not when I do the initial "./configure ...". Am I missing something? By the way, why does libxml++ force the programmer to use a non-standard string class? I am using std::string's to store raw UTF-8 strings everywhere and this will just add overhead to my program. I think a better way is to have libxml++ use std::string and have a method that returns the encoding of the document so that the application can do whatever encoding conversion it wants with the std::string and the encoding.
> ./configure: line 19912: syntax error near unexpected token `5.6.0' Are you using autogen.sh? > why does libxml++ force the programmer to use a non-standard string class? It doesn't force you to do anything. You don't have to use libxml++. For many people, API simplicity is more important. Support for multiple (runtime-discovered) encodings in the API would lead to massive confusion, and it wouldn't be you who'd have to help everyone to use it. It's also not supported by libxml, for the same reasons.
(In reply to comment #7) > > ./configure: line 19912: syntax error near unexpected token `5.6.0' > > Are you using autogen.sh? > No. Should I? I am just doing: ./configure --without-ustring make then it blows.
> > Are you using autogen.sh? > > > > No. Should I? Probably, yes, though you'll need up-to-date autotools. Something seems to have caused aclocal to be called without the extra options that you'll see in autogen.sh.
We want to use libxml++ in a simple application where we even do our own data validation. We don't want to use Glib at all due to the install time dependencies across multiple platforms. Our application seems to work using version 1.0.4 but it is unclear how many other people use this. As the patch to 2.** is not liked and this bug is still unconfirmed what is the recommended course of action? Stick with 1.0.x or use a patched 2.x?
Oh, and I should have mentioned that we had to remove the unnecessary ; from the extern "C" {} blocks before we could build version 1. The change log for version 2 implies that something along those lines was done. Any chance of that fix being put into version 1 as without it we could not build version 1.0.4?
> We don't want to use Glib at all due to the install time dependencies across multiple platforms. If you are talking about Linux platforms then you'll want to use the regular package management of those distros, with the regular libxml++ package for those distros. The default ABI/API of libxml++ 2 will never break, because applications depend on it. If, for some reason, you want to create your own packages that install in parallel, then you could just use the patch. > Oh, and I should have mentioned that we had to remove the unnecessary ; from the extern "C" {} blocks before we could build version 1 If you upload a patch then we could apply it to the old branch.
Created attachment 71419 [details] [review] package and you can do ./configure --with-std-string without dependency on Glib::ustring Using std::string has a big performance boost over Glib::ustring. This is useful if you don't want to deal with the crappy interface for libxml2 but don't want the overhead of Glib::ustring when you're using std::string encoded in utf-8 everywhere. Instead of Glib::ustring in the API, I changed it to xmlpp::string that would be typedef'd to std::string if --with-std-string=yes is given to configure, or Glib::ustring otherwise. This is tested adequately. I wish this could be included in the standard package so we won't need to apply the patch every time there is a new version of libxml++.
Created attachment 71420 [details] package in which you can do ./configure --with-std-string without dependency on Glib::ustring [sorry, please delete my previous post about this bug. i chose the wrong mime type for the attachment ] Using std::string has a big performance boost over Glib::ustring. This is useful if you don't want to deal with the crappy interface for libxml2 but don't want the overhead of Glib::ustring when you're using std::string encoded in utf-8 everywhere. Instead of Glib::ustring in the API, I changed it to xmlpp::string that would be typedef'd to std::string if --with-std-string=yes is given to configure, or Glib::ustring otherwise. This is tested adequately. I wish this could be included in the standard package so we won't need to apply the patch every time there is a new version of libxml++.
David, that appears to be a tarball of the entire source code. Please upload a _patch_. For instance, in a cvs checkout, do cvs diff -up > something.patch
David, it would still be nice to have that patch here.
Created attachment 81966 [details] [review] patch to make libxml++ independent of Glib::ustring. Hi Murray, here's the diff. You might want to leave out the spec file for creating the rpm because it does ./confgure --with-std-string=yes by default.
Sorry to be a pain, but could you please upload a -u diff against svn. For instance, svn diff > something.patch That's much easier to read. And yes, please leave the spec file out of it. It's not related.
I don't use svn. Is it okay for me to just give you the diff -u output with the spec file left out?
Yeah, OK. It will still contain diffs of generated files, but that's not the end of the world.
Created attachment 82254 [details] [review] patch to make libxml++ independent of Glib::ustring. Thanks Murray. Here it is.
This probably needs to be updated for the latest version.
It would be nice if someone updated this patch, for the people who care about it.
I'm ready to update the patch if it has a chance of making it into the official release. But if the maintainers continue to be opposed to making life simpler for people using non-Linux platforms, it seems useless to persist with this.
It's not likely to be committed. I don't want too many configure-time-choosable alternative versions of the API because that makes it difficult for application developers. There's no point in arguing about that again. The patch would be for people who disagree.
And still nobody cares enough to update the patch.
Created attachment 166774 [details] [review] Glib::ustring -> xmlpp::string patch This patch is an updated version of the _first_ part of David Yan's change. This simply renames all the use of Glib::ustring to xmlpp::string and introduces the string.h header file that defines it as Glib::ustring.
libxml++-5.0 can be built without glibmm and libsigc++. There is not yet a stable release of the libxml++-5.0 ABI series, only the unstable libxml++ 4.9.1. libxml++ is now stored at GitHub, https://github.com/libxmlplusplus/libxmlplusplus
As I couldn't wait for 15 years for this bug resolution, I switched to xmlwrapp (https://github.com/vslavik/xmlwrapp/) for all my C++ projects a long time ago but glad to hear this is finally resolved.