Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Brian Kuhl (kuhlenough_at_[hidden])
Date: 2018-11-21 16:23:20
The ideal is always to upstream, I've done a bit of that it past. Other
patches carry forward, but we certainly don't "try" to do that. When you
bundle open source you become focused on the release you've bundled and
rest of the world moves on. We are not like a big Linux distro that grabs
every new release. Upstreaming then requires moving your "fix" to the head
of the tree, and working with the maintainer to make sure it's portable and
generic and follows projects conventions. That takes time and effort, and
sometimes get's stalled in the "business" priority queue. I'm speaking
here of the primarily of proprietary VxWorks and Boost effort, Wind River
also has other products where the focus is different; and virtually the
whole product is "open" e.g. https://www.starlingx.io/ and the "value
proposition" for customers is different.
On Wed, 21 Nov 2018 at 03:47, Hans Dembinski via Boost <
> Hi Daniela,
> > On 20. Nov 2018, at 20:14, Daniela Engert via Boost <
> boost_at_[hidden]> wrote:
> > Am 19.11.2018 um 20:20 schrieb Brian Kuhl via Boost:
> >> Many of our customers make certified systems ( Planes, Trains, Medical
> >> Equipment, Factory Automation, etc. ) and the trend in theses
> industries is
> >> to be pedantic about eliminating all compiler warnings.
> > I run our in-house Boost distribution with the same policy (geared
> > towards Visual Studio). It took me tons of work over several years to
> > get there but during the process of auditing every warning (and dealing
> > with it one way or the other) I actually found errors. Beyond that, the
> > tests have to pass not only in debug build like the test matrix does but
> > also in release build, plus both 32 bit and 64 bit. Each one of the four
> > modes exhibits different sets of warnings and errors in some libraries.
> > Some libraries are poster-childs of careful programming, others - even
> > new ones - less so.
> > That may sound egregious but this is how we develop our software for
> > industrial QA machines.
> just for my curiosity, are you regularly merging these changes back
> upstream into Boost or do you maintain a list of patches to apply to each
> new Boost release?
> Best regards,
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk