Kevin Buckley wrote: >>> The suggestion above is that gettext only needs it for Glade >>> support. >> That's true. So far, only Glade support in gettext requires an XML >> parser. > > I think that's the key for me. It seems as though it is only > Glade-related input to gettext which requires XML parsing and not > anything from other LFS components. Gettext usually handles PO > format, not XML. Input from XML would be an additonal, optional, > feature.
Mmmm... not quite. It's not reading the data that's normally stored in .po files for these tests. gettext the program accepts .po format, yes (converting each file to a .mo compiled version, for the gettext() function to use at runtime). But when you're developing, you have to build the .po files somehow (well, the .pot file; either way), and the standard way to do this is to use xgettext. xgettext extracts all the translatable strings from lots of languages' source files, and also from glade-schema XML files that describe your UI (obviously only if you use gtk and glade). It also supports a bunch of other formats, I believe. But that glade support functionality is what's being tested here, and it's what requires an XML parser. Mind you, that whole set of tests seems a bit pointless to me, since glade's own XML schema is going away in favor of the GtkBuilder support built into recent versions of GTK+. (glade3 now writes out files in this schema, though it may be able to do the old schema as well.) OTOH maybe they test how well xgettext supports that schema, as well? That'd require a parser too, of course. > Until such time as a package that an LFS system requires cannot > itself function without parsing XML, then there's seemingly no need > for utiliites that handle XML to be in the LFS system. xgettext may or may not be able to function (against glade files) without an XML parser. I'm not sure. Of course, xgettext isn't used when building packages either, only when developing them. > Sounds to me, through a "pipeline mentality" ear-trumpet that Glade's > XML should be translated into something gettext can handle but I > guess that (a gettext feature creep?) is obviously a much bigger > issue and not one for LFS. That's more or less what xgettext does. :-P However -- the curmudgeon in me doesn't really want to see an XML parser in LFS, either, whether it's libxml2 or expat. So if it isn't too hard to suppress the failure ourselves, let's do it, and note that rebuilding the package when libxml2/expat is available will enable extra functionality. Or something like that.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
