Re: [lmi] [PATCH] Allow installing wxWidgets from GitHub

[Greg Chicares]

On 2015-08-05 03:01, Vadim Zeitlin wrote:
> On Wed, 05 Aug 2015 01:39:08 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I've amused myself by paying homage
> GC>   http://lists.nongnu.org/archive/html/lmi/2015-05/msg00001.html
> GC> to alt.bad.clams
> 
> [OT: that's a first USENET mention I see since a long, long time. And, of
>  course, it's an alt.* group. Weeds survive best.]

Is that an established proverb? Google doesn't recognize it:
  https://www.google.com/search?q="weeds+survive+best";
at least not in English.

> GC> Arguably the SHA sum is enough, and the tarball's md5sum is unneeded,
> GC> but I'm glad you left it in--I prefer to keep it just in case.
> 
>  I left it mostly because I wanted to minimize the amount of changes, but
> I'm not really sure if it's a good idea to check MD5 of the downloaded ZIP.
> It's enough for GitHub to switch to a different ZIP library (or even a
> different compression level) to invalidate all of them and I don't see any
> good reason to assume that they will never do it, these archives are
> ephemeral. OTOH so far they haven't changed their way of generating them
> AFAIK, so this is all rather theoretic.

Hmm. Then it can actually do harm, so I should either be on the lookout,
or just drop it. Let me sleep on it (motto of alt.music.meat-loaf).

> GC> Probably the only interesting change I've made is
> GC>     ifneq "$(origin wx_md5)" "$(origin wx_commit_sha)"
> GC> in order to make it possible to use only one conditional section;
> GC> but that won't survive if I build in overriding values.
> 
>  What value does using origin bring here? In principle there is nothing
> wrong in doing "wx_commit_sha=xxx make wx_md5=yyy", but this would fail
> this test. Granted, there doesn't seem to be any good reason to do it like
> this, but why forbid it?

I didn't think of that problem. I did think of another, though: what if
$(wx_commit_sha) was set in another makefile that invokes this one, and
$(wx_md5) was set earlier in this makefile--and thus didn't get overridden
when it should have? It looks like $(origin ) isn't the right tool. We
could work around that by creating a $(wx_md5_override) variable that is
by default not defined. But it's probably best to finesse this problem
by overriding the values right inside this makefile.

>  BTW, while you're looking at the makefiles I'd like to ask if you'd be
> interested in the patches refactoring them to try to reuse more code among
> them.

Please don't. It pains me not to accept careful, correct work that
you've done just because our tastes sometimes differ greatly. Much
better just to mention a refactoring idea briefly, like...

> Notably, I'd like to put the make fragments for downloading
> zip/tar.gz/tar.bz2 files in a single place and just use them from
> elsewhere because I was rather annoyed that I had to repeat them once again
> in the wxPdfDocument installation makefile.

The lmi makefiles are well tested and AFAIK free of grave error; why
take any risk for such little gain? It takes a lot of effort to test
a patch that affects multiple makefiles--effort I'd rather spend on
something else. Or, if we were going to refactor them at all, it might
be best to refactor massively and test once...but let's not do that
this decade. At any rate, I see it as an advantage, in a way, for the
makefiles to be largely self-contained: if I'm studying or modifying
one, it's easier to work with if everything's right there in one file.

Besides, those fragments do vary across files. The '%.tar.[whatever]'
and '%.zip' recipes differ between 'install_miscellanea.make' and
'install_wx.make', for example. We could make them more generic, I'm
sure, at the cost of abstrusity, but then we'd be condemned to reinvent
automake, badly, as they used to say in comp.something-or-other.