Re: [lmi] Upgrading to gcc-4.9.2

[Greg Chicares]

On 2015-12-17 23:46, Vadim Zeitlin wrote:
> On Thu, 17 Dec 2015 23:41:52 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> It's still not usable because, e.g.:
> GC> 
> GC> Error
> GC> Assertion 'infinity<double>() == limits_.back()' failed.
> GC> [file /lmi/src/lmi/stratified_charges.cpp, line 137]
> GC> 
> GC> which was foretold by unit tests.
> 
>  Should I be looking at/trying to fix this or is this useless because you
> will take of it yourself anyhow?

I propose that you deal with
 - autotools
 - PCH
 - updating xmlwrapp
 - updating boost
while I handle
 - lmi makefiles
 - backporting the major RTL improvements from mingw.org
 - the extremely few legitimate warnings in lmi code
 - patching cgicc
and then each of us can think he got the easy task-set, or at least the one
that's certain to be practicable.

We need to proceed cautiously, as we must not break our production system.
I think I'll put my local changes off to the side, revert to the mingw.org
toolchain, and apply each change to lmi trunk carefully. Then switching to
MinGW-w64 is a single step, which my coworkers can test carefully; we'll
make the switch only when we're comfortable with it.

Let's judge the risk and priority of each task on the list above:

 - autotools
Not used in production, so zero risk. There might be an enormous benefit
for me if this means I can cross compile. Here are the custom options that
I intend to use for the new toolchain as opposed to the old:
    -std=c++11
    -Wno-unused-local-typedefs
    -Wno-conversion
    -Wno-unused-variable
    -Wno-deprecated-declarations
    -Wno-float-conversion
    -Wno-attributes
    -Wno-parentheses
at least for now.

 - lmi makefiles
I want to preserve the possibility of building with the mingw.org toolchain
at least for now, because switching to MinGW-w64 is an enormous risk.

 - PCH
I haven't reread our historical discussion yet, but from our discussion
earlier today I have the impression that there's a sweeping change that
affects hundreds of lmi files, which we can make with no real risk because
it demonstrably affects only the borland toolchain. Actually using PCH
may introduce some risk of which I'm not aware, so I'll need to investigate
it; we shouldn't bother trying to use it with the mingw.org toolchain. I'm
hoping this will make lmi build significantly faster with the MinGW-w64
toolchain; if it does, then it's a high priority.

 - patching cgicc
Not used in production, so zero risk.

 - the extremely few legitimate warnings in lmi code
They're trivial, and I can handle them with no real risk.

 - updating xmlwrapp
Not urgent: '-Wno-deprecated-declarations' permits us to use the current
version, which entails no risk.

 - backporting the major RTL improvements from mingw.org
This is an absolute requirement. It can be done while we continue to use
the mingw.org toolchain, as we'll just be importing RTL code that we're
already using.

 - updating boost
I've made changes in:
  /opt/lmi/third_party/include/boost/mpl
  /opt/lmi/third_party/include/boost/mpl/aux_
  /opt/lmi/third_party/include/boost/numeric/ublas
  /opt/lmi/third_party/include/boost/numeric/ublas/detail
which I'll commit as a '.patch' file. You will probably recoil at these
changes, and you can of course propose an alternative patch, but I'm
very sure that it's less risky to change one major component at a time,
and the compiler toolchain comes first. I think updating boost is quite
risky, and I'm not convinced it's necessary.

I conclude that the priority order is:
 - backporting the major RTL improvements from mingw.org
 - lmi makefiles
without which we can't use the new toolchain
 - PCH
 - autotools
which promise to make our work go faster
 - the extremely few legitimate warnings in lmi code
 - patching cgicc
which are trivial, and then last of all
 - updating xmlwrapp
 - updating boost
for which I see no compelling case.

Oh--if we're going to write contemporary C++, then I can no longer use
comeau, but we really should have a second compiler. What about Clang?