Re: [lmi] [PATCH] Add script allowing to install any wxWidgets version from Git

[Vadim Zeitlin]

On Thu, 5 Apr 2018 14:43:50 +0000 Greg Chicares <address@hidden> wrote:

GC> There's always more for me to learn, e.g., here:
GC>     git rev-parse --quiet --verify "$wx_commit_sha^{commit}" >/dev/null || 
git fetch $wx_git_url
GC> where at first I thought this:
GC>   "$wx_commit_sha^{commit}"
GC> was a novel shell parameter substitution for environment variable $commit,
GC> except it can't be, because that expression would by default expand to:
GC>   41045df7ea5f93e4c07c1bd846d7127a372705bd^{commit}
GC> so it's the "^{type} peeling operator".

 Yes, and I have to admit that I looked up git-rev-parse(1) before writing
this (I knew I could do something like this, but I wasn't sure about the
exact syntax). Seeing as it's documented write under the --verify option
description, which I use here, I felt that it wouldn't be unreasonable to
use it in the script without further explanation as it could be found in
the man page if needed.

GC> I imagine that this:
GC>   [ "$wx_skip_clean" = 1 ] || git clean -dfx
GC> is for your personal use only, and Kim and I would normally want the default
GC> git-clean behavior, which might derange your wx work in progress.

 Yes, this was mostly to speed up testing by avoiding having to rebuild
every time.

GC> Here:
GC>   gcc_version=`${mingw_bin_dir}${host_type}-gcc -dumpversion|tr -d '.\r'`
GC> I don't think 'install_wx.make' removed '\r'; removing it might do nothing,
GC> or might save us hours of debugging someday, so it's good.

 I think that MinGW make might take care of removing it automatically when
returning $(shell) result, but /bin/sh definitely doesn't when expanding
`...`, so I had to do it explicitly.

GC> I'm not sure why 'install_wx.make' and 'install_wx.sh' both remove any
GC> '.';

 FWIW the only reason install_wx.sh does it is because install_wx.make did
it. Generally speaking, I tried to preserve the existing behaviour as much
as possible, only diverging from it when there was a specific reason to do
it.

GC> it seems regrettable because it makes gcc-11.1.1 and gcc-11.11
GC> indistinguishable.

 In practice, this probably doesn't risk happening with the new gcc
numbering, where the new major version is what used to be the minor one,
but I agree that removing periods still doesn't seem useful.

GC> Would there be any practical disadvantage to changing this:
GC>   wx_cc_flags=-fno-omit-frame-pointer
GC>   wx_cxx_flags=$wx_cc_flags
GC> to this:
GC>   wx_cc_flags=-fno-omit-frame-pointer
GC>   wx_cxx_flags=-fno-omit-frame-pointer
GC> ?

 No, I just thought to avoid unnecessary repetition.

GC> The rationale in various makefiles is that this flag is crucial:
GC>   commit 50b1e9d154014e2f75881cfcce0c4b097dfd0337
GC>     Specify '-fno-omit-frame-pointer' to override the MinGW-w64 default,
GC>     because that toolchain default prevents useful backtraces. See:
GC>       https://lists.gnu.org/archive/html/lmi/2016-06/msg00091.html
GC>       https://lists.gnu.org/archive/html/lmi/2016-07/msg00008.html
GC> so we want it for C++ even if $wx_cc_flags is overridden.

 Note that it's not really possible to override this shell variable, unlike
with the makefile one.

GC> The old wx makefile also specified '-std=c++11', which differs from
GC> lmi's '-std=c++17'; is either of those relevant for wx though?

 There is no difference between C++11 and C++17 when building wx and, in
principle, it could be built in C++98 mode too (which has the advantage of
being much faster than building it in C++11 mode, unfortunately...), and
still be compatible with the application built using C++17.

 In principle, I'd still say that we ought to use --with-cxx=17, just to be
on the totally safe side and use exactly the same compiler options for
everything, but the wxWidgets version currently used by lmi
(41045df7ea5f93e4c07c1bd846d7127a372705bd) doesn't support "17" as the
value of this option yet, so using it would have prevented the script from
working. And, as mentioned above, I wanted to avoid diverging from the
existing install_wx.make, so, finally, I kept it like this. I'd be fine
with changing this "11" to "17" later, after upgrading wxWidgets (but it
would also be fine to not do it).


GC> > If you already have a local wxWidgets repository clone, you will also
GC> > want to set wx_git_url to the path of this repository to speed up the
GC> > initial checkout (although, unfortunately, it won't affect the
GC> > submodules, which will still have to be [slowly] cloned from GitHub,
GC> > even if you already have them too -- of course, this only needs to be
GC> > done once, but it's still annoying).
GC> 
GC> Is there no other way? I ask because github is sometimes unreachable,
GC> and the lmi install* makefiles try to maintain cached copies of
GC> everything to immunize themselves against server faults--as long as
GC> the cache is up to date, they don't even need an internet connection.
GC> Of course, we never had to deal with git submodules in the past. But
GC> I'd like to hope that we could maintain a full mirror somewhere like
GC> /srv/cache_for_lmi or "C:\cache_for_lmi" and then use that as the
GC> source for both the "main" repository and all submodules.

 I don't think it can be done using Git itself, it has no way of knowing
the local submodules URLs. It does support relative paths for submodules
and we could change them from the current

        url = https://github.com/wxWidgets/zlib.git

in .gitmodules to

        url = ../zlib.git

and then "git clone --recursive" would use local mirror of zlib. But you'd
still have to create c:\cache_for_lmi\zlib.git, instead of just cloning the
existing c:\cache_for_lmi\wxWidgets\src\zlib. And this would also break
"git clone --recursive" when cloning local mirror by default. So I don't
know if it's worth it, perhaps I should float this idea on wx-dev...

 But if we really want to clone the latter (src\zlib) path for the
submodules, we need some way to create it from wx_git_url. I think using
"${wx_git_url%/*}/src/zlib" would work for this, but it would need to be
done for each submodule independently and so the install script would need
to be updated whenever any new submodules are added (or changed/removed).
Admittedly, this shouldn't happen very often, so it probably won't be a big
burden. Please let me know if you think I should do it like this -- or if
you have any better ideas, of course!

 Thanks,
VZ