Re: [lmi] [PATCH] Integrate wxPdfDocument into lmi build system

[Vadim Zeitlin]

On Fri, 07 Aug 2015 02:05:59 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2015-07-24 00:21, Vadim Zeitlin wrote:
GC> > 
GC> > Don't disable wxRegEx when building wxWidgets.
GC> 
GC> Committed 20150807T0003Z, revision 6234.
GC> 
GC> > Handle more options in portable wx-config.
GC> 
GC> Committed 20150807T0007Z, revision 6235.
GC> 
GC> > Install wxPdfDocument library as part of lmi installation.
GC> 
GC> Committed 20150807T0025Z, revision 6236.
GC> 
GC> > Add a simple unit test for wxPdfDocument.
GC> 
GC> Committed 20150807T0037Z, revision 6237.

 Thank you! I'll commit the autotools part of the changes soon.

GC> I didn't expect the new test to be added to $(unit_test_targets), and I
GC> don't see how it'll link...
GC> 
GC> wx_pdfdoc_test$(EXEEXT): \
GC>   $(common_test_objects) \
GC>   wx_pdfdoc_test.o \
GC> 
GC> ...without the wxPdfDoc library.

 It does link because of the following line in workhorse.make:

wx_pdfdoc_test$(EXEEXT): EXTRA_LDFLAGS := $(wx_pdfdoc_ldflags) $(wx_ldflags)

I added this there because there already was a similar line for
wx_test$(EXEEXT) and so I chose to be consistent, even if I admit that it
took me some time to find how did wx_test link without bringing in the wx
libraries...

GC> BTW, grabbing patches from the nongnu.org email archives is convenient
GC> (especially if real email and lmi development are separated by a VM
GC> barrier), but the archives perform interesting substitutions:
GC> 
GC> -   cd $(cache_dir) && [ -e $@ ] || $(WGET) $(WGETFLAGS) 
--output-document=$@ $(address@hidden)
GC> +   cd $(cache_dir) && [ -e $@ ] || $(WGET) $(WGETFLAGS) 
--output-document=$@ $(address@hidden)
GC> -   cd $(cache_dir) && $(ECHO) "$(address@hidden) *$@" | $(MD5SUM) --check
GC> +   cd $(cache_dir) && $(ECHO) "$(address@hidden) *$@" | $(MD5SUM) --check

 Ah, this is very thoughtful indeed. As you might have probably guessed, my
answer to all these problems with patches -- as well to anything else
related to the source code management -- is git. If you used it (even just
via git-svn, as I do), you could pull my changes from anywhere (here, your
other machine, GitHub, ...) and apply them easily.

 Otherwise all I can propose is to just make the patch files available
somewhere on the web, would it be helpful if I did it for the next patch
series?

 Regards,
VZ