lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Fixing libxslt build with MinGW 10 and using submodules for th


From: Greg Chicares
Subject: Re: [lmi] Fixing libxslt build with MinGW 10 and using submodules for third-party libraries
Date: Tue, 22 Sep 2020 02:48:53 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 2020-09-21 22:09, Vadim Zeitlin wrote:
>  Hello yet again,
> 
>  While testing building of lmi with MinGW-w64 10.1 we've run into problems
> when building libxslt. One of these problems has been already fixed by the
> upstream, while the other one hasn't been, so we have the choice between
> updating the latest release including the first fix and applying our patch
> for the second fix on top of it, or just applying both patches on top of
> the current version.

We've been using the same version of libxml2 and family since forever.
I think we should upgrade to the latest, to celebrate the new century.
I'm assuming it has to work, since lmi's use of it is not exotic, and
it's used successfully in countless projects.

>  I can, and will, of course, provide patches implementing the solution you
> prefer once you will let me know which one this would be and I'd also like
> to understand how is it possible that you haven't run into these problems
> yourself.

I've no idea. I can send you complete build logs if you like.
I know we have them, because it's always a chore to skip over all
the warnings they elicit. And I know we've built everything from
source using MinGW-w64 gcc-10.0 no more than about a month ago.
If you try running the monster 'lmi_*' scripts in a VM, I can't
imagine any way that could fail to reproduce our success.

>  However beyond this, I'd like to return to my proposal to use Git
> submodules for the third party libraries instead of downloading them via
> FTP and patching them manually. Our last discussion about this started at
> https://lists.nongnu.org/archive/html/lmi/2019-09/msg00013.html seems to
> have petered out without really reaching any conclusion, in spite of the
> initially positive reception. Rereading it, it looks that the main reason
> for this might have been the fear of breaking something before the major
> Halloween release of lmi. Of course, by now we're close to another
> Halloween, but I am not sure if this means that another major release is
> planned for it?

The major releases planned for this year are 30 Sept and 31 Dec, and
we do not currently plan to release any new lmi binary between those
dates, so this is a good time to migrate to submodules, and to a
twenty-first-century set of libraries (except boost, which we're
close to dropping if gcc-10's filesystem is good enough). A libxml2
(etc.) upgrade should be no big deal, because AIUI every project
under the sun uses it, and upgrades smoothly much more often than
lmi has.

>  If not, I'd really like to at least experiment with using submodules.
> Concretely, right now I'd like to add third_party/libxslt submodule and
> change install_libxml2_libxslt.make to use it.
> 
>  Should I go ahead with this?

Sure. And don't keep that thing as a makefile if you don't want to.
Turning the old wxWidgets and wxPdfDoc makefiles into scripts was
a big win; a libx{ml2,slt} script might be similarly better.

The only potential problem I see is if this introduces some kind
of dependency on xmlsoft.org, because that site might not be
accessible from a corporate server. But if they have a github
mirror, we know the corporation allows access to that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]