Stephan Bergmann, on jeu. 22 févr. 2018 15:49:40 +0100, wrote:
> That means external/lxml will need to:
>
> * build against and run with either the system Python or the locally-built
> one from external/python3,
>
> * build against and run with either the system libxml2/libxslt or the
> locally-built one from external/{libxml2,libxslt}.
>
> That's four different ways how to build external/lxml, and slightly more
> different ways (using the system lxml versus external/lxml) how to run the
> gla11y tool in solenv/gbuild/UIConfig.mk. And getting all those ways to
> work, on the different platforms, will be hell.
Well, python, libxml2 and libxslt are very-well-established projects
with a huge lot of reverse dependencies, and thus they have to take
backward compatibility into extremely careful consideration. I thus
don't fear too much problems building lxml against various versions of
them.
(and the current building issue reported in gerrit 50115 is merely that
the current LO python3 module doesn't install any header file or such)
> Isn't there another option to make that gla11y tool process XML data, one
> that better matches LO's needs?
Well, we can reimplement the world for sure.
More seriously, we can of course at least depend only on libxml2. Not
depending on a higher-level library, however, means to have to
reimplement all the tree browsing functions needed to reach the pieces
of .ui files. And avoiding python means, writing all of this in C?
That's neither fun nor easy to extend for further .ui checking. The
eventual script we plan to integrate is only about 300 lines of python.
I'm scared by the maintenance of the equivalent without using python and
lxml more than maintenance of building lxml.
Samuel
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
