On 05/10/2013 04:46 AM, José Matos wrote:
On Thursday 09 May 2013 14:21:37 Richard Heck wrote:
On Linux, of course, it is different. One would just expect this library
already to be installed. But things do not work that way on the other OSs.
Richard
From the webpage:
"Libxml2 is known to be very portable, the library should build and work without
serious troubles on a variety of systems (Linux, Unix, Windows, CygWin, MacOS, MacOS X,
RISC Os, OS/2, VMS, QNX, MVS, VxWorks, ...)"
Or are you thinking about any other system that is not included in this list?
:-)
No, I just meant that we would have to include it in our sources, since
we cannot rely upon libxml to be available on actual machines that are
running non-Linux OSs. It's available for that OS, yes, but it's not
actually going to be installed. Unlike on Linux, where it either is
installed or else we can rely upon package managers to handle the
dependency.
libxml is a proven package that due to its license is widely used, it is easy
to install and it has a very record in terms of stability.
What would be the disadvantage of relying on it? I mean what are concerns about
depending on it?
As Pavel said, if we are using some XML library to read and write LyX
files, then we have to be especially careful that LyX does not get
broken by some external change over which we have no control. (I'll add
to his mention of python the whole mess over losing fork() on OSX.) This
is yet another reason we need whatever library we use to be included in
our code. And then the concern about libxml is the one I mentioned
previously: Between libxml and libxml++, we're looking at 50+MB of code.
More than all of LyX. That'd be worth it if we were actually going to
use much of what libxml provides. But I doubt that is true.
Richard
