David Abrahams wrote:

...

/usr/local/src/boost.cvs/libs/python/build/../src/object/function.cpp:101: warning: right-handoperand of comma has no effect

PyObject_INIT(p, &function_type);

That's probably because PyObject_INIT is a macro defined like this:

#define PyObject_INIT(op, typeobj) \ ( (op)->ob_type = (typeobj), _Py_NewReference((PyObject *)(op)), (op)

) ^^^^

So that has no effect. To GCC I say: so what? The macro is supplied by Python, so there's not much _I_ can do about it.

FYI, you can cast the expression to void if you are going to ignore the fact that it "returns" a pointer. Giovanni Bajo

Slightly related meta-fix I would request once more: please silence all warnings out of boost python binding, at least in the interface users will use. (In fact the same applies to all of boost, but I only recall seeing problems with python bits.) In past releases there have been many trivial warnings such as unused arguments that would have been simple to silence. As they tend to drown us in "instantiated here" type of chains for each actual warning, it is very difficult to see any real problems with our own code. We compile with GCC using -ansi -pedantic -W -Wall and a few other warning options, and it is not unusual that the python bindings do not either compile at all (have to remove -pedantic), or swamp us with warnings. I'd recommend that boost uses the above options + -Werror with GCC to make sure no warnings can creep into the release. If you need a list of outstanding problems with most recent release or some current release candidate, please let me know. Lassi -- I'm not young enough to know everything. --Oscar Wilde

Vladimir Prus writes:

Lassi A.Tuura wrote:

...

Slightly related meta-fix I would request once more: please silence all warnings out of boost python binding, at least in the interface users will use. (In fact the same applies to all of boost, but I only recall seeing problems with python bits.)

Aleksey, is it possible to represent warning in regression test results somehow?

Unfortunately, not without hacking "process_jam_log", which we don't have resources for at this point.

Missing warning information is the only drawback of the current results format.

It's on our todo list.

...

I'd recommend that boost uses the above options + -Werror with GCC to make sure no warnings can creep into the release.

Maybe, this is a good idea. At least, it will make ignoring warnings much harder.

Does Boost.Build provide a feature to enable it accross compilers? -- Aleksey Gurtovoy MetaCommunications Engineering