Re: [lmi] PATCH: disable the of system libraries when building wx

[Greg Chicares]

On 2020-07-23 12:40, Vadim Zeitlin wrote:
> On Thu, 23 Jul 2020 10:58:00 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...there are some libraries that lmi really doesn't need...]
>  If we're really, really certain not to use some library, the simplest
> solution remains to disable it completely. Please note that I don't have
> any objections against doing this, I'd just like to still be able to build
> lmi using a standard wx build too, which is why I disable wxUSE_APPLE_IEEE
> and wxUSE_GIF checks in wx_checks.cpp in my own branch.

Well...even though you don't object to my excluding a particular library,
it creates extra work for you, because it necessitates maintaining your
own branch. And perhaps it also means that lmi depends on a custom wx
build, and can never use a prebuilt debian or cygwin wx package.

And what is gained by excluding any of these libraries? FSF no longer
cares about GIF because the US patent has expired:
  https://www.gnu.org/philosophy/gif.en.html#venuenote
As for that apple IEEE thing...

https://docs.wxwidgets.org/3.0.4/classwx_data_output_stream.html
| The default format for the floating point types is 80 bit "extended
| precision" unless wxUSE_APPLE_IEEE was turned off during the library
| compilation, in which case extended precision is not available at all.

For lmi, we've been building with
  --disable-apple_ieee
According to the documentation quoted above, this means that extended
precision is not available at all...on apple platforms only, I suppose?
It demonstrably doesn't prevent lmi from using extended precision itself,
but maybe it prevents our custom wx build from using extended precision
internally, even for msw? That doesn't sound plausible. But my concern is:

  // License not obviously compatible with GPL. <-- MY CONCERN
  #if wxUSE_APPLE_IEEE
  #   error Disable wxUSE_APPLE_IEEE in wx setup.
  #endif // wxUSE_APPLE_IEEE

and if that affects only apple operating systems, do I care? Does this
package
  https://packages.debian.org/source/stretch/wxwidgets3.0
inhibit that apple thing--and if debian's okay with it, why would I care?
Do I care enough to create extra work for you, or to prevent myself from
someday using that debian wx package with lmi?

Furthermore,
  
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/float.3.html
| On Intel macs, the type long double corresponds to IEEE-754 double
| extended precision.
so maybe the question is irrelevant in this century.

And at any rate we hope ere long to release only 64-bit builds of lmi,
rendering the whole issue moot (unless we want to be the only people
on the planet using gcc's experimental SSE+x87 feature). (Precision
does matter for compound-interest calculations, but for that use case,
64-bit log1p() and expm1() are more accurate than 80-bit log() and exp()
anyway--I think we have a unit test that demonstrates that.)

I'm thinking maybe we should just get rid of
  --disable-apple_ieee
  --disable-gif
for lmi.

>  Yes, but I need to revert or modify the last commit, which I've added
> there for resting of USE_SO_ATTRIBUTES=1 problem only. I also need to
> rebase it on the latest master in order for you to be able to merge it by
> fast-forwarding, as I suppose you still don't want to create any merge
> commits.

Your message arrived just as I was trying to do that myself. I got as
far as this:

git rebase --rebase-merges=rebase-cousins 
--onto=67eea3a465c835473f1676fb9544caa5fb25a9d1 xanadu/ci-workflow
Successfully rebased and updated detached HEAD.

and thought I might be able to turn that into a new branch that I
could fast-forward merge, preserving the linearity I treasure as
well as your history.  But then I wondered whether you really wanted
me to include your "REVERT" commit. Fortunately, you took care of
all of that:

>  I've done it now and rearranged the commits, so that the one discussed
> above is now the first one: even if we don't use real merges (which allow
> grouping the related commits together in a branch), I'd still prefer to at
> least have the related commits be grouped together.
> 
>  The new commit SHA-1 is 4d51cc6d6e8f68628ce6fb1affc8b1028938f0cf and you
> can already fast-forward to it ("git merge 4d51cc6") already. For the rest
> of the PR 145, I wouldn't mind if you merged it now neither, of course, but

Merged and pushed.

> I want to add MSW 64 builds to it too, and ideally I'd like to also add the
> Linux build and run all the tests during these builds automatically). Ideal
> would be for me to "own" this file, i.e. be able to commit changes to it
> myself, as I currently can do with configure.ac and Makefile.am.
> 
>  Would this be acceptable?

Yes.