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

[Vadim Zeitlin]

On Wed, 05 Aug 2015 04:44:00 +0000 Greg Chicares <address@hidden> wrote:

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

 No, just a fact of life, really.

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

 If you continue like this, I'm going to get my yearly dose of USENET in
just a couple more posts!

GC> > GC> Probably the only interesting change I've made is
GC> > GC>     ifneq "$(origin wx_md5)" "$(origin wx_commit_sha)"
GC> > GC> in order to make it possible to use only one conditional section;
GC> > GC> but that won't survive if I build in overriding values.
GC> > 
GC> >  What value does using origin bring here? In principle there is nothing
GC> > wrong in doing "wx_commit_sha=xxx make wx_md5=yyy", but this would fail
GC> > this test. Granted, there doesn't seem to be any good reason to do it like
GC> > this, but why forbid it?
GC> 
GC> I didn't think of that problem. I did think of another, though: what if
GC> $(wx_commit_sha) was set in another makefile that invokes this one, and
GC> $(wx_md5) was set earlier in this makefile--and thus didn't get overridden
GC> when it should have?

 I see. To be honest this problem might well be more realistic.

GC> It looks like $(origin ) isn't the right tool.

 I still think this is the case though. I'd just check whether none or both
variables are defined in the beginning of this makefile to avoid this.
Whether they're both defined on make command line, in the environment or
in another makefile shouldn't matter, just the fact that we inherit both
(or neither, of course) of them.

GC> Besides, those fragments do vary across files. The '%.tar.[whatever]'
GC> and '%.zip' recipes differ between 'install_miscellanea.make' and
GC> 'install_wx.make', for example.

 Well, this is part of the problem: it took me some time to understand why
did they differ and which one I should copy in install_wxpdfdoc.make.

GC> We could make them more generic, I'm sure, at the cost of abstrusity,
GC> but then we'd be condemned to reinvent automake, badly, as they used to
GC> say in comp.something-or-other.

 Unfortunately automake wouldn't help with these install_*.make makefiles.
I do still believe that using it for building lmi itself would be a good
idea, but I'll wait a decade or two before returning to this...

 For now, no patches but just one question about something that puzzled me
a lot: why do we use --timestamping option with wget when we only invoke it
when the file doesn't exist? See

% g grep -F '$(WGETFLAGS)'
install_libxml2_libxslt.make:   cd $(cache_dir) && [ -e $*.md5sum ] || $(WGET) 
$(WGETFLAGS) $(wget_whence)/$*.md5sum
install_libxml2_libxslt.make:   cd $(cache_dir) && [ -e $@        ] || $(WGET) 
$(WGETFLAGS) $(wget_whence)/$@
install_mingw.make:     cd $(cache_dir) && [ -e $@ ] || $(WGET) $(WGETFLAGS) 
$(mirror)/$@
install_miscellanea.make:       cd $(cache_dir) && [ -e $@ ] || $(WGET) 
$(WGETFLAGS) $(address@hidden)
install_miscellanea.make:       cd $(cache_dir) && [ -e $@ ] || $(WGET) 
$(WGETFLAGS) $(address@hidden)
install_miscellanea.make:       cd $(cache_dir) && [ -e $@ ] || $(WGET) 
$(WGETFLAGS) $(address@hidden)
install_mpatrol.make:   cd $(cache_dir) && [ -e $@ ] || $(WGET) $(WGETFLAGS) 
$(address@hidden)
install_wx.make:        cd $(cache_dir) && [ -e $@ ] || $(WGET) $(WGETFLAGS) 
$(address@hidden)

It would seem to be useless then as time stamping is to determine whether
the file needs to be updated from server and here it's always the case. I
thought it was just to give the correct timestamp to the file, but this is
already the case by default, you have to use --no-use-server-timestamps
explicitly to change this.

 The reason I looked into this was the incompatibility of --timestamping
with --output-document (which makes sense). I spent some time thinking
about how I could still use --timestamping even with the latter before
realizing that it shouldn't be used at all. And now I think it should be
removed from the places where it is currently used just to avoid such head
scratching in the future.

 Regards,
VZ