Building Libs for Windows Debug Version with VS2017/Qt5.12

Having trouble installing or compiling FreeCAD? Get help here.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by wmayer »

sgrogan wrote: Sat Mar 23, 2019 3:57 pm
wmayer wrote: Sat Mar 23, 2019 3:45 pm From your GH fork I downloaded the file FreeCAD-LibPack_12.1.1.zip. However, it doesn't seem to be a valid zip file. So what kind of file should this be and what content does it have?
The libpack is here: https://github.com/apeltauer/FreeCAD/releases
I have the Libpack downloaded too. But I also wanted to know what the file FreeCAD-LibPack_12.1.1.zip is supposed to be.

Today I have installed VS2017 build tools + the Win10 SDK. So far I was able to build FreeCAD and most of its modules (only those that depend on smesh I couldn't build).

Now when I try to run the unit tests it crashes very quickly. Somehow there is a problem when I try to load the DraftGui module. An assertio dialog appears and says that inside cpython/modules/gcmodule.c the expression _PyGCHead_REFS(gc) != 0 is false.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by sgrogan »

wmayer wrote: Sat Mar 23, 2019 5:06 pm I have the Libpack downloaded too. But I also wanted to know what the file FreeCAD-LibPack_12.1.1.zip is supposed to be.
I cannot find this file?
wmayer wrote: Sat Mar 23, 2019 5:06 pm Now when I try to run the unit tests it crashes very quickly. Somehow there is a problem when I try to load the DraftGui module. An assertio dialog appears and says that inside cpython/modules/gcmodule.c the expression _PyGCHead_REFS(gc) != 0 is false.
On the version below, I only get a WebGui error when running self tests, DraftGui is no problem. I think I copied folders iconengines, imageformats, and sqldrivers from the platforms directory (sibling to bin in the Libpack) to bin

OS: Windows 7 SP 1 (6.1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16182 (Git)
Build type: Release
Branch: (HEAD detached at LibPack_12.1.1)
Hash: c01936fa495456fcb52b4e78f859c78e82bc9095
Python version: 3.7.2
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)
"fight the good fight"
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by wmayer »

The file appears on the web page as "Source code (zip)".
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by wmayer »

Then I found another oddity: the debug version area_d.pyd links against the release version of boost-python instead of the debug version.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by sgrogan »

wmayer wrote: Sat Mar 23, 2019 5:58 pm The file appears on the web page as "Source code (zip)".
This is the actual FreeCAD source code at the tag. It seems to be a valid .zip file for me. It gets named because of the tag of the release, hence the LibPack in the filename.
"fight the good fight"
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by wmayer »

sgrogan wrote: Sat Mar 23, 2019 6:05 pm
wmayer wrote: Sat Mar 23, 2019 5:58 pm The file appears on the web page as "Source code (zip)".
This is the actual FreeCAD source code at the tag. It seems to be a valid .zip file for me. It gets named because of the tag of the release, hence the LibPack in the filename.
Ok, then I don't need it anayway. I thought that it could have been the source code of the 3rd party libraries.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by sgrogan »

wmayer wrote: Sat Mar 23, 2019 5:06 pm Now when I try to run the unit tests it crashes very quickly. Somehow there is a problem when I try to load the DraftGui module. An assertio dialog appears and says that inside cpython/modules/gcmodule.c the expression _PyGCHead_REFS(gc) != 0 is false.
I'm doing a release build. I will try a debug build.
"fight the good fight"
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by wmayer »

apeltauer wrote: Sat Mar 23, 2019 9:38 am You can try. I think better then nothing...
I have to get my automation build pipeline back to work with the new Libpack, then I can try to get FEM back to work...
Btw. I think compiling fc with VS2017 takes longer then with VS2013?!?
I have installed the VS2017 environment on another machine than that I use on a daily basis. And this other machine actually has a better hardware and more CPU cores but the build process is much, much slower. When I built the release version yesterday then it took almost an hour while on my daily used machine using VS2013 it takes around 30 minutes for a full build.

On the other hand as said before I had the chance to access a Win10 machine with SSDs in it and there the build process took around 15 minutes. So, obviously the limiting factor is not the compiler but somehow the hardware or some things (like a virus scanner) slows down the procedure.
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by wmayer »

apeltauer wrote: Tue Mar 19, 2019 1:30 pm Update:
Release build works just fine. Tests are good except of one in the ship workbench. see pic:
Capture.PNG

Also the web stuff does not work yet. In qt5 the webkit is depricated for the webenging. I tried to merge the PR (https://github.com/FreeCAD/FreeCAD/pull/1937) from mumme74. But it throws an exception.
For now their is no start page...
I have the impression that Python 3.7.2 is the culprit. Something must be wrong with the garbage collector. As said yesterday it constsantly crashes when I import DraftGui -- I assume it's caused by importing pivy internally. But when I explictly import pivy before DraftGui then sometimes it works.
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Building Libs for Windows Debug Version with VS2017/Qt5.12

Post by wmayer »

Comments to your PR:
I was able to build FreeCAD without using this PR. The only change I had to make was extending PCL_INCLUDE_DIRS to find the header files for pcl-1.9. The rest was only switching on or off some options in the cmake-gui.

Code: Select all

    IF(DEFINED ENV{FREECAD_LIBPACK_DIR})
      set(FREECAD_LIBPACK_DIR $ENV{FREECAD_LIBPACK_DIR} CACHE PATH  "Directory of the FreeCAD LibPack")
      MESSAGE(STATUS "Found libpack env variable: ${FREECAD_LIBPACK_DIR}")
      IF(EXISTS ${FREECAD_LIBPACK_DIR}/lib/Qt5Core.lib)
        OPTION(BUILD_QT5 "Build with Qt5." ON)
      ELSE()
        OPTION(BUILD_QT5 "Build with Qt5." OFF)
      ENDIF()
    ELSE()
        set(FREECAD_LIBPACK_DIR ${CMAKE_SOURCE_DIR} CACHE PATH  "Directory of the FreeCAD LibPack")
    ENDIF()
This makes sense as it avoids to run cmake configure multiple times.

Code: Select all

        # FIXME: --> for now disable fem
        if(EXISTS ${FREECAD_LIBPACK_DIR}/LipPackVersion.txt)
          SET(BUILD_SMESH OFF)
          SET(BUILD_FEM OFF)
          SET(BUILD_FEM_NETGEN OFF)
        endif()
Currently, the libpack lacks of either the med stuff or the external smesh so that at the moment FEM cannot be built. But IMO there should be no such check in the CMakeLists.txt that automatically disables certain modules. Sure, it's a minor inconvenience to run configure twice but this is because the libpack is not yet complete and once done this check is not needed anyway.

Code: Select all

FindOpenCasCade.cmake
I didn't need these changes either. Your libpack lacks of some cmake config files that are used to tell cmake which libraries must be used. The clbundler mechanism uses this line:

Code: Select all

set(OCE_DIR ${FREECAD_LIBPACK_DIR}/lib/cmake CACHE PATH "" FORCE)
where it searches for requested config files.
In the top-level CMakeLists.txt file we request the OpenCasCade package which then loads the file FindOpenCasCade.cmake. Depending on whether the Community Edition (OCE) or the official version is requested it use this line

Code: Select all

find_package(OCE QUIET)
or this line

Code: Select all

find_package(OpenCASCADE CONFIG QUIET)
Internally cmake looks for the files OCEConfig.cmake or OpenCASCADEConfig.cmake which are expected to be in $FREECAD_LIBPACK_DIR/lib/cmake. With attached zip file you should be able to extend your libpack without the need to touch FindOpenCasCade.cmake.

Code: Select all

UseLibPackCLbundler.cmake
The changes you made are way too specific to your libpack. Again the recommended way is to put the cmake config files to the libpack so that the general mechanism is able to find all needed information.
At the moment my local build lacks of shiboken/PySide support but this is what I look next.
Attachments
OCEConfig.zip
(10.69 KiB) Downloaded 63 times
Post Reply