Re: [lmi] Using Git submodules for the dependencies

[Vadim Zeitlin]

On Fri, 20 Sep 2019 15:08:08 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-09-20 12:46, Vadim Zeitlin wrote:
GC> > 
GC> >  Another issue which arose again when thinking about the Linux build is
GC> > that of getting the sources of various dependencies. We already have the
GC> > existing install_xxx.{make,sh} scripts that do it, of course, and it
GC> > probably shouldn't even take much, if anything, to make them work under
GC> > Linux, but I can't help wondering why do we reimplement something that Git
GC> > can perfectly well to do on its own.
GC> 
GC> That may be a good idea.

 OK, I'd like to propose to switching to using submodules for at least
wxWidgets and wxPdfDocument then. Ideally I'd also like to use them for
xmlwrapp and Boost.Filesystem (as long as we still use it) and maybe even
libxml2, i.e. everything that we need to compile, but it's probably better
to start with the maximally useful minimum change.

 I think we may have touched on this already, but unfortunately I don't
remember the conclusion, so I'd just like to ask you again where would you
like to create the submodules (i.e. "mount points" of wxWidgets etc
repositories in lmi source tree)? Personally I always use "3rdparty"
directory for them, with it being appealing because "3" makes it clearly
different from everything else, but I believe you might have expressed a
preference for "third_party" in the past? Other people use "libs", but I
don't like it that much because we might conceivably want to have other
things than the libraries in a submodule as well.

 Similarly, I wonder where would you want the submodule URLs to point to.
We could just continue using https://github.com/wxWidgets/wxWidgets.git and
https://github.com/vadz/wxpdfdoc.git as we do now in install_wx*.sh, but
perhaps you want to use some repositories on Savannah instead? This can be
changed later, but if you already know which repositories do you want to
reference, it would make sense to start by using them immediately. Of
course, if you don't, then you don't really need to waste time thinking
about it and I can just use the same URLs as now.


GC> On the other hand, I'm not sure the version of git that we're
GC> working with supports submodules.

 What is the minimum version of Git that we need to support? The current
(and the previous, and even the one before, and ...) Cygwin version
definitely supports them.


GC> At this point, I'm struggling to get anything done on the
GC> server.

 Setting it up initially might take some time, but I'm surprised it's as
onerous as that. Of course, there is always the "when all you have is
Debian, any Linux looks like an OS where you can install it in a chroot"
approach, i.e. you could use debootstrap to create a chroot of Buster on
this machine and just do everything inside it with minimal drawbacks (a few
hundred of extra MiB of disk consumption). But even though I prefer Debian
to RedHat, I still think it shouldn't be that difficult to configure the
latter for software development.

GC> Each incremental step exposes more problems. For
GC> example, installing EPEL didn't let me install MinGW-w64, but
GC> I was able to do that with 'yum install --nogpgcheck'. I'd
GC> like to post here a list of all the changes I'm making, but
GC> first I need to figure out what changes are necessary. If (as
GC> I think you said in a private message) you're able to install
GC> the same version of RHEL we're using, then I should post what
GC> I've done now, and then we could work on the remaining issues
GC> together--two heads are better than one, especially when the
GC> first one's mine and the second one, yours.

 I mostly avoid RedHat, but I do have to build things under it quite often,
so I can indeed try to help. And I'll install it here a.s.a.p. in any case.

 Regards,
VZ

pgpxexWmSl6ZO.pgp
Description: PGP signature