[Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...

[sgrogan]

Does it also merit to mention OCC TBB support in Help > About FreeCAD ?

Yup, that's where we started, but in the process of trying to get this to work abdullah realized we are not compiling FreeCAD correctly w/TBB.

[abdullah]

OK. This diff effectively activates the HAVE_TBB preprocesor macro in FC:

and makes FC stop compiling

Code: Select all

[ 62%] Building CXX object src/Mod/Spreadsheet/Gui/CMakeFiles/SpreadsheetGui.dir/AppSpreadsheetGui.cpp.o
src/Mod/Import/App/CMakeFiles/Import.dir/build.make:251: recipe for target 'Mod/Import/Import.so' failed
CMakeFiles/Makefile2:3648: recipe for target 'src/Mod/Import/App/CMakeFiles/Import.dir/all' failed
CMakeFiles/Import.dir/ImportOCAF.cpp.o: In function `tbb::task_group_context::task_group_context(tbb::task_group_context::kind_type, unsigned long)':
/usr/include/tbb/task.h:450: undefined reference to `tbb::task_group_context::init()'
CMakeFiles/Import.dir/ImportOCAF.cpp.o: In function `tbb::task::task()':
/usr/include/tbb/task.h:556: undefined reference to `vtable for tbb::task'

[abdullah]

Apparently there was another HAVE_TBB macro defined in ImportOCAF.cpp :

Code: Select all

#ifdef HAVE_TBB
#include <tbb/parallel_for.h>
#include <tbb/blocked_range.h>
#include <tbb/task_group.h>
#endif

However, when this is activated the importer fails to compile. I guess the TBB implementation of this importer was simply broken and it silently compiled because, even if TBB was present in the system, nothing was enabling it when compiling...

[abdullah]

I do not quite like that OCC defines the macro as HAVE_TBB. I think projects should better name their specific macros, e.g. OCC_HAVE_TBB, as an application using different projects may end up with various HAVE_TBB macros. When these macros are part of the include files, a mess is served (or I ignore how the get out of it if there is a way).

[abdullah]

OS: Ubuntu 16.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.11122 (Git)
Build type: Debug
Branch: occ_extra_info
Hash: a0da4b16a8768779ce32480046d3c0109595d5e5
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0 (TBB)

So it is possible to mark whether OCC was build with TBB support or not.

The code I used:
https://github.com/abdullahtahiriyo/Fre ... extra_info

It is intended as an example only, as I guess we should:
1. Fix the CMake so that the cmake from OCC are loaded and whether HAVE_TBB was used when compiling OCC extracted from there.
2. Find a solution for OCAF. I am not sure what.
3. Decided what we want to show and how.

I was thinking to show something like above, because we can not know against which version of TBB OCC was compiled. We can surely get the TBB library version existing in the system. However that is a different thing I guess. Also if this works, I am not sure if it would be interesting to add other compilations options to OCC information like VTK...

[sgrogan]

It is intended as an example only, as I guess we should:
1. Fix the CMake so that the cmake from OCC are loaded and whether HAVE_TBB was used when compiling OCC extracted from there.
2. Find a solution for OCAF. I am not sure what.
3. Decided what we want to show and how.

Thanks abdullah for continuing to pursue this. I'm am in the process of repeating on windows. Maybe a too old version of tbb on linux is a problem? I sure hope not and would be surprised that occ compile didn't fail because of it.

For 1. we probably need to consider what happens if the information can't be found and FreeCAD falls back to finding paths to specific files.
For 2. Let's see what happens on Win. I'm using recent pre-compiled binaries from intel for tbb.
For 3. I would say what is used by FreeCAD, but in the case occ is compiled with a different version of VTK than we use for FreeCAD there could be conflicts.

Dependencies of dependencies gives me a headache. Pull the thread on the blanket and soon we have a ball of yarn and no blanket

[abdullah]

For 1. we probably need to consider what happens if the information can't be found and FreeCAD falls back to finding paths to specific files.

I think that we cannot invent information we do not have. If we fall back to path finding, then probably the HAVE_TBB macro should not be set and (TBB) should not appear (regardless of how it was compiled). I mean, if cmake does not find what OCC should have put in its path when installing, then the "mistake" is in the OCC compilation/installing/packaging, not in FC.

Dependencies of dependencies gives me a headache. Pull the thread on the blanket and soon we have a ball of yarn and no blanket

I guess that in part is why cmake exists and allows to do so many things. If it would be straightforward we would not need it.

[sgrogan]

I think that we cannot invent information we do not have. If we fall back to path finding, then probably the HAVE_TBB macro should not be set and (TBB) should not appear (regardless of how it was compiled). I mean, if cmake does not find what OCC should have put in its path when installing, then the "mistake" is in the OCC compilation/installing/packaging, not in FC.

Agreed, we can not invent it. It should be reported as unknown (look at About FreeCAD info for build type).

I guess that in part is why cmake exists and allows to do so many things. If it would be straightforward we would not need it.

Agreed again When Cmake works it is a huge aid. I can't compile most stuff that doesn't use it. But when there is an error in Cmake it is difficult to recover. See in FreeCAD all wmayer's work with VTK to overcome upstream Cmake/packaging errors.

[abdullah]

abdullah wrote:
I think that we cannot invent information we do not have. If we fall back to path finding, then probably the HAVE_TBB macro should not be set and (TBB) should not appear (regardless of how it was compiled). I mean, if cmake does not find what OCC should have put in its path when installing, then the "mistake" is in the OCC compilation/installing/packaging, not in FC.


Agreed, we can not invent it. It should be reported as unknown (look at About FreeCAD info for build type).

I am not sure we can report it as unknown. I mean we can report a TBB version of the system as unknown. However:
a) when HAVE_TBB is set: OCC has TBB support
b) when HAVE_TBB is not set: either OCC has no TBB support or we can not detect whether it has it.

Trying to split the second one into two states (TBB not supported and TBB not detected) is rather impossible (if you can not detect something because your detector is of a bad quality, you cannot known if there isn't that something or you cannot detect it, the solution is to get a better detector). Here I would say the solution is also "fix the bug that prevents the detection".

The on a separate point, I was hopping we would not bloat the debug output with too much information, so reporting only what is detected, something like a one liner like this (the things in parenthesis only if they make sense to report, just an example):

OCC version: 7.1.0 (TBB, VTK, OPENMP)

However, I am very open to any other form that is more useful, nicer...

[abdullah]

Agreed, we can not invent it. It should be reported as unknown (look at About FreeCAD info for build type).

This is slightly another thing but related. If TBB is enabled in FC (so if there is a MACRO defining that FreeCAD shall be built with TBB support, for example for the OCAF, for example for the OCC bindings, for any of those), then we can also report the TBB version:

OS: Ubuntu 16.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.11122 +2 (Git)
Build type: Debug
Branch: occ_extra_info
Hash: ba1e1d03d1b48bb9f6bb05baabcaf2bcef48d890
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0 (TBB)
TBB version: 9.2

Currently I am using only the HAVE_TBB macro, as we have to figure the rest out first, but this is a possibility:

https://github.com/abdullahtahiriyo/Fre ... extra_info