BIND 10 #365: clang++ support
BIND 10 Development
do-not-reply at isc.org
Wed Oct 13 07:18:10 UTC 2010
#365: clang++ support
-------------------------------+--------------------------------------------
Reporter: jinmei | Owner: UnAssigned
Type: enhancement | Status: reviewing
Priority: major | Milestone: y2 12 month milestone
Component: build system | Resolution:
Keywords: | Sensitive: 0
Estimatedhours: 0.0 | Hours: 0
Billable: 1 | Totalhours: 0
Internal: 0 |
-------------------------------+--------------------------------------------
Comment(by jinmei):
Replying to [comment:4 each]:
> > - older versions of boost doesn't explicitly support clang++, so I
simply (and implicitly) required boost >= 1.44
>
> Just to make sure... that requirement only pertains if building with
clang++, right?
>
Right.
> Because 1.44 is very recent and most OS distributions won't likely have
it yet.
>
Right, and that's exactly why I introduced the additional
-I<path_to_boost>.
> > I didn't dig into why, but clang++ probably handles "false" in some
tricky way. I didn't change the "true" patterns because it didn't trigger
an error and when we can use EXPECT_EQ it would be better than
EXPECT_TRUE.
>
> I don't understand this last point. Why is it better to use EXPECT_EQ()
when possible? EXPECT_TRUE() is simpler and clearer.
>
On second thought, I think you're right. I was thinking cases like
{{{
EXPECT_TRUE(<exp1> == <exp2>); // should be EXPECT_EQ(<exp1>, <exp2>)
}}}
but it doesn't make (much) sense to keep the awkward style of
{{{
EXPECT_EQ(true, <expression>);
}}}
So I've chanded the "true" patterns throughout the code tree as well.
It's not a requirement for the clang++ support, but making both
(true/false) patterns consistent in the same branch would be nice. It's
r3197.
--
Ticket URL: <http://bind10.isc.org/ticket/365#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list