Building the whole .debug Libpack?
Are you using QT5 as well?
Building the whole .debug Libpack?
Are you using QT5 as well?
Building the libpack is one thing. It requires a lot of time and memory, e.g. only building Qt5 takes a full day and needs 60GB. Then IMO we should try to support older compiler versions as long as possible and I don't see why for a single class I should upgrade to msvc14.Ah you are right. I forgot about this hurdle.
Can you explain why vs2015 is no option currently for you... I don't see any big show stoppers.
I got it already working for Part faces with almost no effort, it's only for meshes where I have problems.Hmm I have to say, that I do not like the double effort to create the bindings. Any change has to be done on both bindings...
Such solution is not very clean in my eyes. I think it's better to disable the flatmesh library if no pybind11 is available.
I guess adding the gui-commands with c++ is the easier solution to make this functionality available without pybind11. It was only my lack of c++ knowledge, why I have chosen to use python for the gui...I got it already working for Part faces with almost no effort, it's only for meshes where I have problems.
I am just saying to not support the flatmesh for builds without pybind11. I am not saying we have to move to newer compilers. I don't want to make building/developing for FreeCAD more difficult, and I don't want to develop the boost-python bindings, if I change anything inside this library.Then IMO we should try to support older compiler versions as long as possible and I don't see why for a single class I should upgrade to msvc14.
On the other hand having a Python binding is always good because:I guess adding the gui-commands with c++ is the easier solution to make this functionality available without pybind11. It was only my lack of c++ knowledge, why I have chosen to use python for the gui...
Well, for me the main point was to see what the result of the flattening will be and due to the lack of C++14 support I used boost.python as alternative. Also, I never used boost.python before and it is a good opportunity to get familiar with it a bit.I am just saying to not support the flatmesh for builds without pybind11. I am not saying we have to move to newer compilers. I don't want to make building/developing for FreeCAD more difficult, and I don't want to develop the boost-python bindings, if I change anything inside this library.
nice to know.On the other hand having a Python binding is always good because:
1. the GUI actions are macro recordable
2. it helps to reduce or avoid hard dependencies at build time.
Do you mean to build boost.python or using the library? At least with version 1.67 we recently also had a problem to detect it via cmake because now the component name must include Python's version number, i.e. instead of writingI have experienced build difficulties with boost-python already, and I am not the biggest fan of this library...
Code: Select all
find_package( Boost COMPONENTS python REQUIRED)
Code: Select all
find_package( Boost COMPONENTS python36 REQUIRED)
Indeed that would be great.Anyway, in my eyes adding support for numpy<->eigen wrapping with pycxx would be the ideal solution.
using the library. pybind11 is much simpler because it is header only.Do you mean to build boost.python or using the library?
any ideas where to start?indeed that would be great.
No, I first have to have a closer look at the offered solutions.any ideas where to start?