Re: [lmi] Testing build with native MinGW 4.9.1

[Greg Chicares]

On 2016-01-22 14:27, Vadim Zeitlin wrote:
> On Fri, 22 Jan 2016 06:19:45 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-01-21 20:09, Vadim Zeitlin wrote:
> GC> > 
> GC> >  I'm not sure what is the relationship between the version and
> GC> > cross-compiling
> GC> 
> GC> I have a dream: I use GNU/Linux exclusively for writing code and testing 
> it;
> GC> others who run msw exclusively compile the same code and distribute it to
> GC> end users; and both versions behave identically, so I don't ever have to
> GC> boot an msw machine except to verify that the behavior is identical or to
> GC> investigate some OS-specific quirk. To bridge the OS gap, I need to be 
> able
> GC> to cross compile.
> 
>  Unfortunately I don't think this dream is very realistic because there
> will inevitably be some platform-specific quirks. We can try to minimize
> them, but the behaviour of MSW and GTK GUIs are just never going to be the
> same and, compared with this major difference, the differences between
> libxml2 2.9.1 and 2.9.5 or whatever is really negligible.

I suppose we just have different points of view. To me, lmi is a numerical
program that performs insurance calculations; it has an incidental GUI as
a concession to end users who don't wish to use the command line and edit
input files by hand. If I can get a GNU/Linux build to produce exactly the
same numbers as a native msw build, my dream is fulfilled, and any GUI
differences are just quirks from this POV--whereas a difference of 1 ulp
between two runtime libraries' expm1() results might be painful.

But from that POV, it doesn't matter what version of libxml2 is used, as
long as it correctly implements the tiny part of that library's capabilities
that lmi actually uses (and probably every stable xmlsoft.org release does
that), and therefore...

> GC> There seem to be two ways I can use the same version of library X for
> GC> both x86_64-linux-gnu and i686-w64-mingw32:
> GC>  (1) choose the version provided with my OS, and use that for both; or
> GC>  (2) choose any version we like, perhaps the latest, and build it from
> GC>      upstream (not debian) sources for both--which means keeping the
> GC>      x86_64-linux-gnu builds outside the normal FHS locations.
> GC> I was just thinking that (1) would be easier, and perhaps it is at first;
> GC> but (2) shouldn't be much more work, and seems better for the long term.
> GC> What do you think?
> 
>  I agree that (1) is easier than (2), but I think the easiest of all is
> 
> (3) use the OS version for native Debian builds and the latest version when
>     building from source.

...yes, (3) is the sensible way.