I have a MacPorts ticket requesting that I enable CTRLPORT, which
requires Thrift, which was recently updated to 0.10.0 in MacPorts -- so
I thought it worth a try again to see if it works.
Thrift requires C++11 for building, which means that "gnuradio
+ctrlport" will also require C++11. Easy enough, or so I thought, by
forcing CMake to use C++11 via using the right compiler and adding
"-DCMAKE_CXX_STANDARD=11" as a commandline argument.
This combination works well until it reaches gr-fec, which errors out
due to a BOOST_CONSTEXPR_OR_CONST declaration that's valid C++ when it
is "const" ... but the C++ code isn't valid for a "constexpr", which
requires that the variable value be defined in the declaration.
gr-fec/include/gnuradio/fec/polar_decoder_common.h:70
{{{
private:
static BOOST_CONSTEXPR_OR_CONST float D_LLR_FACTOR;
}}}
gr-fec/lib/polar_decoder_common.cc:37
{{{
const float polar_decoder_common::D_LLR_FACTOR = -2.19722458f;
}}}
Looks like D_LLR_FACTOR was correctly defined to work with the
"constexpr" or "const" version of BOOST_CONSTEXPR_OR_CONST in <
https://github.com/gnuradio/gnuradio/commit/a1cf11937665392bcfa223a5095ff903eb44c69b
> by Jaroslav Škarvada, and then broken in <
https://github.com/gnuradio/gnuradio/commit/a981e6a18c4f28cc6058fef4167c01ad3dc7d58a
> by Josh Blum.
In my searching, the code above is the -only- place where a "constexpr"
is potentially used. Thus, can we please just get rid of it and use
"const" instead? Why the need for a constexpr here and no other place?
One can work around this issue by defining BOOST_NO_CXX11_CONSTEXPR, but
the code should be able to build without this workaround.
Thoughts? Comments? - MLD
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
