sgrogan wrote: ↑Thu Jan 24, 2019 12:50 am
My personal opinion is we should examine conda first. It's a huge task anyway we look at it, but at least the conda trail has been blazed in release mode.
Let's do some theoretic astiimation of the work needed before starting with the work: (List is not yet finished)
qt seems to be the easier dependency:
1. build qt in debug mode
2. build pyside2 ontop of qt-debug-build (I guess we do not need pyside in debug-mode)
boost:
1. build boost on debug mode
2. rebuild coin (in debug mode)
3. rebuild pivy
looo wrote: ↑Sat Jan 26, 2019 8:18 am
why? Can't we use the release builds of these libs?
See wmayer's reply earlier in the thread. Mixing release and debug libs may lead to a crash. In the past, on Win, we have had the trouble with libboost-python debug linking against libpython release.
looo wrote: ↑Thu Jan 24, 2019 9:41 am
Let's do some theoretic astiimation of the work needed before starting with the work:
Thanks for this! An ill fated attempt could waste a lot of resources. Maybe wmayer or peterl94 know the sequence this needs to be done?
I have some possibly terribly naive questions about the windows builds.
1) why are you insisting on using outdated versions of VS instead of the latest "usable" version? VS2013 is meanwhile hard to get anywhere. VS2015 is also outdated and incomplete with regard to C++11 support and there are still some issues in VS2019 but mainly related to SFINAE. Not something I see in use anywhere in the FeeCAD code. I had no serious issues with compiling FreeCAD itself using VS2017 and recently VS2019 and linking to the older libraries in the conda environment. There are some libraries and headers mainly in the NET and MESH region that create issues and I never looked into that because I turn these parts off. But that's more a case of laziness because these are not my specific interests.
2) Do you really need all the libraries in debug? For me it is more important to be able to debug FreeCAD not third party libraries. Is anybody debugging QT, OCC, or Python on a regular basis ? The only one I ever used in debug are the python libraries because of it's entanglement with FreeCAD end even there it was more to get from "one side" to the "other side" and not to look at the details of the interpreter. Unfortunately some headers and libraries, and Python is an example of that, are badly implemented and change the interface when compiled in debug vs. release. Really not a smart move but outside of the realm of FreeCAD and I can imagine that the mentioned issues with boost/python libraries had their origin in that problem. Typically it works fine. One could suggest that via some build switches, if one really needs them, some of the libraries can be made available in their debug version when FreeCAD is compiled in debug. This would require some cmake restructuring. I can see that in most cases if compiled in debug the projects automatically try to pull in the debug versions of the libraries which in turn of course currently breaks the build. That's also where one discovers the bad behaviour of library header files when they see the "DEBUG" define.
3)In an earlier thread I also mentioned that one can actually compile FreeCAD in "Release with Debug info". It's not prefect because of optimizations but one can debug with it. A possible cmake support for this mode would be to turn off the optimizations and possibly inlineing.