lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Finish submodules soon? [Was: Use submodules for, and newer ve


From: Vadim Zeitlin
Subject: Re: [lmi] Finish submodules soon? [Was: Use submodules for, and newer versions of, libxml2 and libxslt]
Date: Fri, 2 Oct 2020 00:18:41 +0200

On Thu, 1 Oct 2020 22:01:45 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 2020-10-01 15:36, Vadim Zeitlin wrote:
GC> [...]
GC> >  I plan to make more PRs to switch to using submodules for wx and wxPdfDoc
GC> > too in the near future. I don't know if it's worth doing it for all
GC> > libraries from install_miscellania.make, but I'd like to do it for at 
least
GC> > xmlwrapp (which, BTW, could/ought to be installed from install_x*.sh now).
GC> 
GC> Can you estimate how long the wx* and *wrapp things would take
GC> to submodule-ize? Would one week be enough?

 Yes, it should be, unless we run into some completely unexpected problems.

GC> Therefore, striking while the iron is hot, this is the perfect
GC> time to submodule-ize the whole lmi universe, including
GC>  - wxWidgets and wxPdfDoc,
GC>  - xmlwrapp and xsltwrapp,

 OK, let me already start with those.

GC> and anything else that should be a submodule. Candidates, from
GC> 'install_miscellanea.make':
GC> 
GC>   xmlwrapp_archive := xmlwrapp-0.9.0.tar.gz
GC> 
GC> Should become a submodule.

 Yes.

GC>   PETE [not in 'install_miscellanea.make']
GC> 
GC> Mentioned because its present location, in src/tools/pete-2.1.1,
GC> seems ideal.

 Does it? It doesn't seem ideal to me, because this is not a tool, so IMO
moving it to thirty_party would be warranted. OTOH making it a submodule
probably isn't because it's not really updated, neither upstream (which
doesn't exist, AFAIK) nor by us. The main reason to create a submodule for
it would be to allow reusing this library in other projects, but I don't
think this is a priority neither.

GC>   boost_archive    := boost_1_33_1.tar.bz2
GC> 
GC> Once we upgrade lmi to use std::filesystem, we might keep this
GC> old archive around for 'test_coding_rules' only, because its
GC> regex implementation is much faster than libstdc++'s was, last
GC> time we looked.

 I'd really like to try using PCRE instead. It's a much more stable and
still maintained library and we could use the system library under Unix.

GC>   cgicc_archive    := cgicc-3.1.4.tar.bz2
GC> 
GC> Same question as for boost: just move it to Spitsbergen,
GC> because it's just a bunch of source files that we aren't
GC> going to pull from upstream?

 It's up to you, i.e. it mostly depends on your plans concerning the future
modifications (or absence thereof) to this code. We probably don't need to
do anything with it right now.

GC>   jing_archive     := jing-20091111.zip
GC>   trang_archive    := trang-20091111.zip
GC> 
GC> Whether it's official or not, this exists:
GC>   https://github.com/relaxng/jing-trang
GC> but do we care? I don't think we'd ever want to build java
GC> stuff from source.

 Hmm, never say never. I'm going to check these 2 once I finish with the
other ones.

GC> Putting that all together, I think we should try to migrate
GC> exactly the things you named:
GC>  - wxWidgets and wxPdfDoc
GC>  - xmlwrapp and xsltwrapp
GC> into submodules, and leave all the others alone.

 Yes, this looks right, thanks for the summary,
VZ

Attachment: pgpvwQTenWIPE.pgp
Description: PGP signature


reply via email to

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