View Issue Details

IDProjectCategoryView StatusLast Update
0000585FreeCADBugpublic2012-03-31 18:04
Reporteryorik Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version0.13 
Summary0000585: Bug with boost 1.48
DescriptionAnyone already using boost 1.48? I think I met this qt bug: http://bugreports.qt-project.org/browse/QTBUG-22829

This happens when compiling FreeCAD:
[ 17%] Generating moc_Control.cpp
usr/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse error at "BOOST_JOIN"
make[2]: *** [src/Gui/moc_Control.cpp] Error 1
make[1]: *** [src/Gui/CMakeFiles/FreeCADGui.dir/all] Error 2
make: *** [all] Error 2
Not sure of the best way to treat this, better leave it to someone more expert!
Additional Informationhttp://bugreports.qt-project.org/browse/QTBUG-22829
TagsNo tags attached.
FreeCAD Information

Activities

yorik

2012-02-03 20:29

administrator   ~0001607

Adding the following line in CMakeLists.txt solves the problem:

add_definitions(-DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED)

But it should probably be added only if boost = 1.48, I'm not sure how to do that...

yorik

2012-02-04 21:09

administrator   ~0001609

curiously, MESSAGE(STATUS "Boost version found: ${Boost_LIB_VERSION}")
returns the wrong version (I have some boost1.46 libs still there), although the version used for building is 1.48...

chinasaurli

2012-03-29 07:46

reporter   ~0001829

Separately, would it make sense to put this BOOST_TT_HAS_OPERATOR_HPP_INCLUDED define inside a #ifdef Q_MOC_RUN? Or doesn't matter?

yorik

2012-03-29 11:29

administrator   ~0001830

Actually it doesn't harm having that definition applied globally, I use it since a couple of weeks without any problem. I would like to find a way to add it only if boost 1.48 is detected (it's a bug between qt and boost, so very likely it will be fixed in later versions), but I can't seem to make cmake detect boost1.48 correctly...

chinasaurli

2012-03-29 14:21

reporter   ~0001831

Last edited: 2012-03-29 14:35

I agree bug fix likely although I don't know how fast Qt gets updated. Boost defines BOOST_VERSION and BOOST_LIB_VERSION in boost/version.hpp, so you could use that? version.hpp is also pretty clean, so should be easy to get this directly from the file system once you have the directory?

(I'm having this issue with current MacPorts boost, which is 1.49.)

I guess I would say if you're sure the HAS_OPERATOR define doesn't harm anything that's great, but if there's any question, I'm think putting it safely inside Q_MOC_RUN will still fix the problem.

yorik

2012-03-29 15:19

administrator   ~0001832

Yes, obviously it is the best way, apply it only if boost >= 1.48 and Q_MOC_RUN. But cmake should be able to detect the boost version, i'm not sure what's wrong

chinasaurli

2012-03-29 15:35

reporter   ~0001833

Do you think it's a problem with the cmake module or something else? I thought it's a module problem so can't really be fixed on that end, but I don't know. The cmake Python module certainly has some issues...

wmayer

2012-03-31 15:37

administrator   ~0001837

Last edited: 2012-03-31 15:38

To make it clear the error 'Parse error at "BOOST_JOIN"' is NOT a compiler error. It's an error raised by the moc utility.

If you check the generated Makefile moc gets passed all the include directories of the build target among them the boost include dirs. For version 1.48 moc can't parse properly the headers. Actually, there is absolutely no need to give moc any include directory (at least no non-Qt related) but this is how cmake does it.

The solution is as shown in the first link of this error report: pass the define BOOST_TT_HAS_OPERATOR_HPP_INCLUDED to moc rather than the compiler.

Fortunately we wrote our own macro in cmake to moc headers so that we can add this change in one central place. And the good thing with this fix is that it does no harm to the compiled sources because the compiler doesn't see the define -- just in case there might be some problems.

Look at git d6061d30a053617b8127c96e8c6a65e47589a182

yorik

2012-03-31 15:49

administrator   ~0001838

oh, very nice way to solve... Everyday one learns a new nice cmake trick :)

wmayer

2012-03-31 18:04

administrator   ~0001839

Fixed in git d6061d30a053617b8127c96e8c6a65e47589a182

Issue History

Date Modified Username Field Change
2012-02-03 12:32 yorik New Issue
2012-02-03 20:29 yorik Note Added: 0001607
2012-02-04 21:09 yorik Note Added: 0001609
2012-03-29 07:46 chinasaurli Note Added: 0001829
2012-03-29 11:29 yorik Note Added: 0001830
2012-03-29 14:21 chinasaurli Note Added: 0001831
2012-03-29 14:22 chinasaurli Note Edited: 0001831
2012-03-29 14:35 chinasaurli Note Edited: 0001831
2012-03-29 15:19 yorik Note Added: 0001832
2012-03-29 15:35 chinasaurli Note Added: 0001833
2012-03-31 15:37 wmayer Note Added: 0001837
2012-03-31 15:38 wmayer Note Edited: 0001837
2012-03-31 15:49 yorik Note Added: 0001838
2012-03-31 18:04 wmayer Note Added: 0001839
2012-03-31 18:04 wmayer Status new => closed
2012-03-31 18:04 wmayer Resolution open => fixed
2012-03-31 18:04 wmayer Fixed in Version => 0.13