Re: [lmi] Using Git submodules for the dependencies

[Greg Chicares]

On 2019-09-20 17:40, Vadim Zeitlin wrote:
> 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.

Okay, I guess, though I'm not sure I understand the ramifications.
Does this simply mean that we'd now add all the wx etc. sources to
lmi's savannah repository? And that then, at our leisure, we could
adjust makefiles and scripts to use those newly local sources? But
that for now nothing would break--i.e., we could continue building
as in the past, and it would still work?

>  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.

We already use "third_party" somewhere, and I hesitate to change
that to "3rdparty" because name changes cost something and I see
little benefit to this particular one.

>  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.

Today, we depend only on gnu.org and other well-known free sites:
the same kind of sites that debian depends on. I very much want
to keep it that way. I don't want to introduce a dependency on
github, because of proverbs about Greeks bearing gifts and
leopards changing their spots.

It's perfectly okay to continue using github as a secondary mirror
as long as savannah remains the primary, complete host.

> 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.

I don't know. Maybe the version we have on redhat does support
submodules, but its failure on
  git clone jobs=
caused me to question that.

> 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.

I don't have your experience.

> 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).

Is that feasible? If so, it sounds like an excellent idea.

BTW, what does "debootstrap" mean? Is it "DEBian bOOTSTRAP",
the first three letters suggesting that it works only on
debian? Or is it "de-bootstrap", some inverse kind of
bootstrapping, which would work on other distros?

> But even though I prefer Debian
> to RedHat, I still think it shouldn't be that difficult to configure the
> latter for software development.

If my debian system had no GUI; and forced me to use a
little rubber keyboard with no Ins key at all (while many
other keys require Fn, like Fn+UpArrow = PgUp), and a
tiny screen, and a touchpad; and terminated any session
after 15 minutes of inactivity--then I'd find debian
pretty hard to use, too.

> 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.

Perhaps I should do the same. After actually installing
fedora (before finding out that's not very close to redhat),
for multi-booting (before you explained that there are
better ways), I looked into installing a centos chroot,
but it seemed like too much work for me, for too little gain.

But if you're going to do that anyway, maybe you could share
your exact steps and I can just ride your coattails. I'd
hesitate to set up a VM (qemu, e.g.) because of prior
negative experiences, but I'm very comfortable with chroot
(or, better, schroot), and willing to learn to use something
like docker if you prefer that.