lmi
[Top][All Lists]
Advanced

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

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


From: Vadim Zeitlin
Subject: Re: [lmi] Updating install_wx.make to get wxWidgets from git
Date: Sun, 25 Mar 2018 14:45:46 +0200

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?

GC> And it would be best to clone into a 'cache_for_lmi' directory.

 OK.

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.

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 and I don't see
any real need to rename it, but please let me know if you do.

GC> Then I started wondering whether we want this repository to be bare.

 I don't see why would we. We need a working copy anyhow and building
wxWidgets in a separate build directory doesn't modify anything in the
source directory (and we can/probably should do "git clean" in it anyhow).

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. But this is indeed
outside of the scope of install_wx.make except in the sense that it should
allow customizing the URL to clone the repository from -- which it will
allow doing, of course, e.g. via "make -f install_wx.make wx_git_url=xxx".

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 or should we start with just a single, normal
repository before adding another, bare, one only if we really need it?

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.

 Regards,
VZ


reply via email to

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