[bind10-dev] 1.0.0 release details

[JINMEI Tatuya / 神明達哉]

At Wed, 20 Feb 2013 08:51:55 -0800 (PST),
"Waitman Gobble" <uzimac at da3m0n8t3r.com> wrote:

> > > If anyone has any other proposal to to delay the final .0 release, 
> > > please let us know (and point to a ticket number).
> > 
> > We haven't received any responses to the -Werror comments on the -dev
> > list. I don't know if we can ignore it; we should discuss this at least
> > among us towards making a decision.

> It's been like a year, but the problem I remember encountering with -Werror had to do with the installed boost version and compiler version, which could cause a warning with cast.hpp, but a 'work around' which seemed to work was wrapping the call to cast.hpp, ie
> https://lists.isc.org/pipermail/bind10-users/2012-February/000242.html
> and 'silenced' the warnings. 
> 
> I'll have to try out a fresh version to see what happens.

Regarding this particular topic, see this:
536.	[build]		jinmei
	Detect a build issue on FreeBSD with g++ 4.2 and Boost installed via
	FreeBSD ports at ./configure time.  This seems to be a bug of
	FreeBSD	ports setup and has been reported to the maintainer:
	http://www.freebsd.org/cgi/query-pr.cgi?pr=174753
	Until it's fixed, you need to build BIND 10 for FreeBSD that has
	this problem with specifying --without-werror, with clang++
	(development version), or with manually extracted Boost header
	files (no compiled Boost library is necessary).
	(Trac #1991, git 6b045bcd1f9613e3835551cdebd2616ea8319a36)

but we now have --without-werror configure option, so at least the
user can specify it to work around such platform-dependent false
warning issues.  The question in this context is, in my understanding,
whether we should suppress -Werror by default in release tar balls.

On which I have a mixed feeling.

- I can imagine people who just stop trying immediately when build
  fails.  Since this is an early stage of the (deployment of the)
  project and we want more people to try it, it's not good to lose
  such candidate users.
- On the other hand, it's probably the case that those who dare to use
  such a new product are more likely to have skills of diagnosing and
  handling these issues, and, hopefully are more willing to report the
  issues to us.  It's generally better to get more such feedbacks,
  especially at the earlier stage of the deployment; suppressing
  -Werror is bad in that sense.
- Yet another thing is that build failure due to -Wall + -Werror could
  really be a bug that does harm for the user, although I suspect it's
  quite unlikely, even more so for C++ than plain old C.  In that
  case, it's obviously better to make it fail, rather than causing
  run-time troubles for the users.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.