corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: libxml2 and iconv question, do we really need iconv ?
Date Mon, 23 Mar 2015 14:42:17 GMT
On 23 March 2015 at 15:03, Peter Kelly <kellypmk@gmail.com> wrote:

> I have about 70% of an XML parser done that I haven’t gotten around to
> finishing yet. Once that’s completed, we don’t need libxml. I can’t
> remember if we need iconv; it’s used for character set conversions but
> DocFormats is UTF-8 native (as is libxml), and support for UTF-16 would not
> be hard (if it’s even needed).
>
> I would strongly argue against keeping sources of libraries in our
> repositories except in the case where we have made changes to those
> libraries. If we do that we have to include all of SDL_image and thus all
> of SDL, and that leads to quite a big repository. The same goes for libz
> etc. Most projects have lots and lots of dependencies and are handled just
> fine by standard package dependency systems e.g. apt-get.
>
I tried to add it to see how much it grows, and yes it is getting bigger.

We do need to modify:
- libz, because there are no 64bit windows version around.
- libxml, because it depends on iconv which has a license apache does not
like (LGL), and because there are no 64bit windows version around
- SDL and SDL_Image we could do without, because the deliver both x32 and
x64.

Btw SDL and SDL_Image why do we need them ?

Can we agree to keep them there until the 64bit version is ready, then we
know how much has really been changed ? If you disagree then I will move it
out again.



>
> Furthermore, we want to use the system libxml where available, both to
> take advantage of shared libraries (libxml only needs to exist in memory
> once, the OS maps it into the address space of each process that uses it),
> and for security updates (system libxml updated due to vulnerability,
> programs using DocFormats are still vulnerable until we go and update our
> own version).
>
I have to ask the license experts again, but I fear when we use the
standard libxml, it includes iconv and I am not sure how that affect us.
(but anyhow if you are nearly finished, that aspect will go away).

You are right about shared libraries, but it makes it complicated on e.g.
windows to test both 32bit and 64bit.


Franz@ since Iconv is LGPL we cannot depend on it.

Is it all about getImageDimension() ? if so it might be easier to simply
write that function.

I am sorry, the new desktop editor, seems to draw bigger circles than I
thought. But the good thing is we get a lot of future problems solved.

rgds
jan I



>
> --
> Dr. Peter M. Kelly
> kellypmk@gmail.com
> http://www.kellypmk.net/
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
> > On 23 Mar 2015, at 3:29 pm, jan i <jani@apache.org> wrote:
> >
> > Hi.
> >
> > I am nearly finished with the x64 port for windows, I have compiled all
> > libraries we need.
> >
> > I wanted to see if we could keep the library sources in our Repo, and
> > integrate them in our build
> > system, as it would simplify things. Since I am biased I asked on
> > general@i.a.o to get the opinion
> > of outside Mentors. I got a few responses (strangely enough all in
> > private), and it turns out many projects do as I suggest.
> >
> > However one of the others mentors found a license problem with iconv. We
> do
> > not use iconv, but by default libxml2 does. I can configure libxml2 not
> to
> > include iconv, but I wanted to ask in here, if we need the functionality
> ?
> >
> > If not my plan has changed a bit, and I will include the sources in
> > platform, make a single commit with each original source, noting the URL
> > and version in the commit text (and add it to LICENSE). Then I will add
> my
> > changes, which will be solely CMAKE files NO source changes.
> >
> > Having the source in our build system, will also allow us to decide how
> to
> > handle other platforms.
> >
> > Rgds
> > jan I.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message