Re: [lmi] Updating install_wx.make to get wxWidgets from git

[Greg Chicares]

On 2018-03-25 12:45, Vadim Zeitlin wrote:
> On Sun, 25 Mar 2018 12:13:58 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> TL;DR: 'git clone' once and only once; something like:
> GC>   https://www.wxwidgets.org/develop/code-repository/
> GC> git clone --recurse-submodules https://github.com/wxWidgets/wxWidgets.git
> 
>  Thanks, I'll do it like this, but in this case I have to say that I'm
> really not sure we need a makefile for it, instead of just a shell script,
> as there are no dependencies we could leverage and no advantage from make
> being able to build several targets in parallel, so, while it's always
> possible to basically just put a shell script inside a makefile, I wonder
> if we shouldn't also replace install_wx.make with install_wx.sh?

Sure, let's try making it a shell script.

As you point out, we can always transform it into a makefile if wanted.
I guess the motivating reason why I've written so many 'install*.make'
files is that 'make' is highly platform-independent, and command-line
interpreters were not so in the 1990s, when we actually used CMD.EXE
and COMMAND.COM (each version of which behaved somewhat differently)
or native msw ports of ash and zsh (which were far from flawless).

> GC> For cygwin, that's "C:\cache_for_lmi". For my chroots, I maintain
> GC>   /srv/cache_for_lmi/
> GC> in my "host", and to create a new chroot I copy its contents, e.g., to
> GC>   /srv/chroot/lmi-buster/cache_for_lmi/
> 
>  I don't know if you really want to have a (deep) copy in order to be able
> to modify it from a chroot without seeing the changes in the host and the
> other chroots, but if you don't, then you might consider using "mount -o
> bind" to just bring the existing host directory in scope of the chroot
> without doing any copying.

I realize it's not a secure BSD jail, but nevertheless a chroot is
at least a significant wrinkle in the attack surface, and I'd like
to keep the chroot as isolated as I easily can. I figure this makes
it easier to port from schroot to, e.g., unprivileged containers.

> GC> Where should this initial wx clone go? Easy: in its own subdirectory:
> GC>   $cache_dir/appropriate_name_for_wx_git_clone
> 
>  Would "wxWidgets" be appropriate enough? It's a natural choice because
> this is the directory "git clone" would create by default

That's perfect. I left it unspecified only because, IIRC, in the
old days different wx release tarballs used different subdirs.

> GC> Then I started wondering whether we want this repository to be bare.
> 
>  I don't see why would we.

Okay.

> GC>  (0) bare, in /srv/cache_for_lmi
> GC> This is outside the scope of 'install_wx.make', and indeed beyond its
> GC> reach, because it's not even visible to any chroot. The analog for Kim
> GC> would be an intranet subdirectory if the intranet worked correctly, but
> GC> in reality an external file-sharing service that actually does work.
> 
>  Having a local mirror of wxWidgets repository an in intranet subdirectory
> could be useful for cloning it quickly (well, much quicker than when using
> Savannah or Github, anyhow) on multiple machines.

(We've found this particular intranet to be unsuitable for such purposes.)

> But this is indeed
> outside of the scope of install_wx.make

Okay.

> GC>  (1) bare, in /src/chroot/buster/cache_for_lmi or C:\cache_for_lmi
> GC>  (2) bare, in /src/chroot/buster/opt/lmi/blessed or C:\opt\lmi\blessed
> GC>  (3) working copy in .../opt/lmi/proprietary
> GC>   
> GC> For wx, I'm guessing we'd want something like (1) and (3).
> 
>  This would work but, again, I'm not sure how is this better than just a
> (normal, not bare) clone in c:\cache_for_lmi.
> 
>  Am I missing something here

Probably not.

> or should we start with just a single, normal
> repository before adding another, bare, one only if we really need it?

Yes, let's do it that way.

> GC> Oh, and while we're doing this for wxWidgets, we should probably do
> GC> exactly the same thing for wxPdfDoc.
> 
>  Yes, but this is much less urgent because it doesn't use submodules and so
> the existing way of getting it works just fine.

Okay, that's a separate step to be undertaken later.