[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] [Monotone-debian] Bug#653764: FTBFS with Boost 1.48
From: |
Hendrik Boom |
Subject: |
Re: [Monotone-devel] [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do' |
Date: |
Sat, 31 Dec 2011 11:02:33 -0500 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote:
> On Fri, Dec 30, 2011 at 9:53 PM, Steve M. Robbins <address@hidden> wrote:
> > This package failed to build using the newest Boost version 1.48:
> ...
> > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp: In
> > function 'T boost::math::detail::lgamma_small_imp(T, T, T, const
> > mpl_::int_<0>&, const Policy&, const L&)':
> ...
> > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp:483:38:
> > error: expected primary-expression before 'do'
>
> I'm not in a position to verify this for myself for another week, but
> I have a horrible feeling I know what's wrong: Monotone defines
> several one-character macros for its own use, and L() is one of them.
> It looks like Boost is using L() for its own purposes and expecting it
> not to be a macro.
>
> I'd argue that Boost headers should take care to defend themselves
> from the possibility of such macros, but fixing that in Boost might be
> an enormous amount of work, and in any case, 1.48 is already out
> there.
>
> If I'm right, this can also be fixed in monotone by moving all Boost
> and stdlib #includes above most-but-not-all application #includes;
> unfortunately that's exactly the opposite coding style from the
> present usage, and may involve messing with the base.hh convention
> (config.h obviously still needs to be the very first thing included in
> every file).
Or by changing the name of L. This could presumably be done using a
program on the source code. It would have to be careful only to change
L where it was a separate word, outside of strings. It should flag L's
in comments for special treatment -- whether it should change them
automatically should probably depend on whether most L's in comments
were mantions of the macro or words (unlikey, but might happen in
abbreviations).
It probably wouldn't even be a long program. It should run on the C++
code, probably not on any code in other languages. Do we ever do
token-pasting with L?
-- hendrik