Ultimaker / cura-build-environment

CMake project to build dependencies for Cura
GNU Affero General Public License v3.0
24 stars 54 forks source link

Issues encountered getting cura-build-environment for Cura 4.9 working on Windows 1904 #95

Open ThomasRahm opened 3 years ago

ThomasRahm commented 3 years ago

Issue 1:

Occurs when trying to build cura-build-environment:

-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.17/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: C:/Users/Thomas/Documents/Cura/cura-build-environment-4.9/b2/CMakeFiles/CMakeTmp

    Run Build Command(s):nmake /nologo cmTC_198bc\fast &&       "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" -f CMakeFiles\cmTC_198bc.dir\build.make /nologo -L                  CMakeFiles\cmTC_198bc.dir\build
    Building C object CMakeFiles/cmTC_198bc.dir/testCCompiler.c.obj
        C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe @C:\Users\Thomas\AppData\Local\Temp\nmC10C.tmp
    cl : Command line warning D9002 : ignoring unknown option '-m64'
    testCCompiler.c
    Linking C executable cmTC_198bc.exe
        "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_198bc.dir --rc=rc --mt=CMAKE_MT-NOTFOUND --manifests  -- C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\cmTC_198bc.dir\objects1.rsp @C:\Users\Thomas\AppData\Local\Temp\nmC284.tmp
    RC Pass 1: command "rc /fo CMakeFiles\cmTC_198bc.dir/manifest.res CMakeFiles\cmTC_198bc.dir/manifest.rc" failed (exit code 0) with the following output:
    The system cannot find the file specifiedNMAKE : fatal error U1077: '"C:\Program Files\CMake\bin\cmake.exe"' : return code '0xffffffff'
    Stop.
    NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
    Stop.

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:4 (project)

Fix:

Change line one in env_win64.bat to call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1

Issue 2:

Happens when trying to start cura(python Cura-4.9\cura_app.py --external-backend) using compiled cura-build-environment (to supply the dependencies):

Traceback (most recent call last):
  File "Cura-4.9\cura_app.py", line 32, in <module>
    from cura.CrashHandler import CrashHandler
  File "C:\Users\Thomas\Documents\Cura\Cura-4.9\cura\CrashHandler.py", line 27, in <module>
    from UM.Application import Application
  File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Application.py", line 9, in <module>
    from UM.Controller import Controller
  File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Controller.py", line 3, in <module>
    from UM.Scene.Iterator.DepthFirstIterator import DepthFirstIterator
  File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Scene\Iterator\DepthFirstIterator.py", line 3, in <module>
    from UM.Scene.SceneNode import SceneNode
  File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Scene\SceneNode.py", line 14, in <module>
    from UM.Mesh.MeshBuilder import MeshBuilder
  File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Mesh\MeshBuilder.py", line 4, in <module>
    from UM.Mesh.MeshData import MeshData
  File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Mesh\MeshData.py", line 16, in <module>
    import scipy.spatial
  File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\spatial\__init__.py", line 102, in <module>
    from ._geometric_slerp import geometric_slerp
  File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\spatial\_geometric_slerp.py", line 8, in <module>
    from scipy.spatial.distance import euclidean
  File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\spatial\distance.py", line 122, in <module>
    from ..special import rel_entr
  File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\special\__init__.py", line 633, in <module>
    from . import _ufuncs
ImportError: DLL load failed while importing _ufuncs: The specified module could not be found.

Fix:

Copy DLLs from cura-build-environment\lib\site-packages\numpy\core to cura-build-environment\lib\site-packages\numpy\DLLs The files seems to be moved away from there in projects/python_packages.cmake line 66ff.

Issue 3:

If python 3.8 is already installed on the System, some of the Savitar module files are copied into the native python installation(for example in appData), and not into the target one(cbe_install_dir).

Fix:

Deinstalling python 3.8 from the system.

Result:

After these changes, the build environment seems to be working for me.

Ghostkeeper commented 3 years ago

It's very kind to see how proactive you are with coming up with solutions to these problems and sharing them.

Change line one in env_win64.bat to call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1

As I understand from documentation, this causes it to use the Windows 8.1 SDK, but currently we can't do that since our build server is still Windows 7. We're working on a migration, but it's apparently a lot of work. Weird though that apparently using the most recent SDK would break the build process? Perhaps there is one such SDK version number that is available for Windows 7 as well. Perhaps @evtrados would like to know about this, as he's been on this issue recently.

Copy DLLs from cura-build-environment\lib\site-packages\numpy\core to cura-build-environment\lib\site-packages\numpy\DLLs The files seems to be moved away from there in projects/python_packages.cmake line 66ff.

Seems like we've more or less encountered the reverse. The DLLs need to be moved to the /core directory because that's where cx_Freeze looks for them. See also https://github.com/marcelotduarte/cx_Freeze/issues/653 .

Issue 3 is indeed a known issue. It also happens for libArcus. It's not a problem in cura-build-environment but rather in those repositories itself. It's very annoying on Linux because the build then suddenly needs administrator access to install things into the Python dist-packages folder.