Re: [lmi] Cross-compiling lmi from Linux to MSW

[Vadim Zeitlin]

On Mon, 25 Jan 2016 05:34:27 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-01-21 20:41, Vadim Zeitlin wrote:
GC> > On Thu, 21 Jan 2016 01:52:31 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2016-01-14 01:35, Vadim Zeitlin wrote:
GC> [...]
GC> > GC> > Notice that the commands above do not use "-std=c++11" for 
compiling for
GC> > GC> > the good reason that Boost 1.38 doesn't build with this option
GC> [...]
GC> > GC> Yet it does seem to compile natively in msw with '-std=c++11',
GC> > GC> so isn't it really strange that the cross-compiler fails?
GC> > 
GC> >  Oops. I know what happened here: I used Boost 1.38 which is used in our
GC> > branch of lmi as we had to upgrade to it to use boost::math::expm1() and
GC> > log1p() 6+ years ago:
GC> 
GC> Yet we use expm1() and log1p() in production, without boost replacements.
GC> I guess you must have done that for msvc,

 I'm not totally sure, all these years after, but I don't think so, I
believe we wanted to use the standard C11 versions of these functions when
they're available and Boost provided a way to do it. Or perhaps it was
related to builds for amd64 architecture? I certainly can try returning to
this if there is any chance of finally dealing with the problem, whatever
it was.

GC> That's really excellent news from my POV. Perhaps I can just add
GC> '-std=c++11' to every compile command, and it'll all just work.

 I really hope so, yes. FWIW I also added --enable-cxx11 to wxWidgets
configure recently, so if you feel adventurous enough to use its latest
version, you could do this instead of fiddling with CXX[FLAGS].

GC> > Just FYI, currently we
GC> > use the following Boost headers:
GC> > 
GC> > ---------------------------------- >8 
--------------------------------------
GC> > % git grep boost/|sed -n 
'/#include/address@hidden<\([a-z_/]*\.hpp\)address@hidden@p'|sort|uniq
GC> 
GC> [snip list]
GC> 
GC> Does standard C++ now provide all of them except 'any' and 'filesystem'?

 Actually not quite, after a more careful look I also found the use of
boost::operators in several places and this is still not in C++11 (and
probably won't even be in C++17).

GC> If so, then we can freeze those two parts and purge the rest.

 This won't be simple, as long as we keep any Boost headers, it's simpler
to keep all of them than trying to extract just their dependencies. In any
case, I don't think it's a problem to use header-only stuff, for me it's
only Boost.Filesystem that is really problematic.

GC> >  To summarize, we can continue using Boost 1.33 for now because it's über
GC> > ancient enough to not have problems with C++11, so upgrading Boost is not
GC> > as urgent as I thought
GC> [...]
GC> >  However I still think that it would be worth it to:
GC> > 
GC> > (a) Replace as much as possible of Boost classes with C++11 ones now that
GC> >     we can do it (this includes scoped_ptr, shared_ptr, regex, ...).
GC> 
GC> Absolutely.

 OK, I'll add it to my C++11-ization TODO sub-list.
VZ