Compile fails using VS 2017

[7ofNine]

Hello,
I am aware that compilation of FreeCAD using Visual Studio 2017 is not heavily supported, nonetheless I was able to do it with some hints taken from the forum and it worked fine until recently. There is a commit on May 28, 2018 (hash: 432daa95c5430ebc539f8e42c844e0590290e201) that brakes the compilation with VS. What happens is that with that commit the character set is changed from multibyte to unicode which in turn brakes the compilation/build of e.g. FreeCADApp, FreeCADGui (and more). So far I failed to identify or find why a cmake change for NETGEN and OCC can have such an effect.
...
2>d:\dev\freecad\src\app\application.cpp(2278): error C2664: 'int WideCharToMultiByte(UINT,DWORD,LPCWCH,int,LPSTR,int,LPCCH,LPBOOL)': cannot convert argument 5 from 'TCHAR [780]' to 'LPSTR'
2>d:\dev\freecad\src\app\application.cpp(2278): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
2>d:\dev\freecad\src\app\application.cpp(2279): error C2679: binary '=': no operator found which takes a right-hand operand of type 'TCHAR [780]' (or there is no acceptable conversion)
2>c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.15.26608\include\xstring(2501): note: could be 'std::basic_string<char,std::char_traits<char>,std::allocator<char>> &std::basic_string<char,std::char_traits<char>,std::allocator<char>>::operator =(const _Elem)'
...

I'll fix it but any idea where to look would be appreciated.

Thanks
Hartmuth

[TheMarkster]

I'd like to compile with vs2017. Can you provide detailed steps on how to do it, assuming you can get it working again?

[wmayer]

It's hardly possible that git commit 432daa95c543 breaks the compilation because Netgen (or OpenCascade is not used) in FreeCADApp. And I don't see that it changes anything about unicode stuff. The change is basically about using the libraries' cmake files to be used when available.

Nevertheless the type TCHAR is defined as wchar_t when UNICODE is set as preprocessor macro and thus causes the failure. To fix it you can replace TCHAR with char in the source code.

[7ofNine]

It seems hardly possible but it is happens as the compile failure clearly indicates.
As a setup I am using a conda environment from the beginning of April for all the libraries.
The "culprit" lies in the use of the parameter "CONFIG" in the "find_package(OpenCASCADE CONFIG QUIET)" in the cmake/FindOpenCasCade.cmake file. This looks for and finds '...\Library\lib\cmake\opencascade\OpenCASCADEConfig.cmake' which ultimately then pulls in '...\Library\lib\cmake\opencascade\OpenCASCADECompileDefinitionsAndFlags-release.cmake'.
This file contains

set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$<CONFIG:Release>:UNICODE>)
set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$<CONFIG:Release>:_UNICODE>)

triggering the problem. The problem is not limited to FreeCADApp, other projects get affected, too . It looks as if the 'UNICODE' is injected on the wrong level in the directory hierarchy. Removing these two lines removes the compilation error.

Cheers
Hartmuth

[wmayer]

The "culprit" lies in the use of the parameter "CONFIG" in the "find_package(OpenCASCADE CONFIG QUIET)" in the cmake/FindOpenCasCade.cmake file. This looks for and finds '...\Library\lib\cmake\opencascade\OpenCASCADEConfig.cmake' which ultimately then pulls in '...\Library\lib\cmake\opencascade\OpenCASCADECompileDefinitionsAndFlags-release.cmake'.

Ah, thanks for the hint.

The problem is not limited to FreeCADApp, other projects get affected, too . It looks as if the 'UNICODE' is injected on the wrong level in the directory hierarchy. Removing these two lines removes the compilation error.

I will set the UNICODE define to see where it breaks the build and prepare some fixes soon.

[wmayer]

This fixes git commit 2e4d2dff0 the build failures I get when UNICODE is defined.

[7ofNine]

@TheMakster: I basically follow what is described in this thread https://forum.freecadweb.org/viewtopic. ... 40#p220932 and it works "fine". One can simply use toolset v141. I don't think there is anything in the FreeCAD code that is really incompatible. The issues arise from the libraries which should be handled via the conda environment. But(!) I am using a conda environment from April and compile for Qt5 and Python 3.6. I had trouble with some missing library in the latest version of the conda environment ( a couple of weeks ago ) and was to lazy to look into it. I am actually pulling in the source from git and use the conda environment only for the libraries, this might create issues, too, but it worked for me.
The wiki is rather weak on all these conda "things", at least the last time I checked it when 0.17 was released.

Cheers
Hartmuth

[sgrogan]

I had trouble with some missing library in the latest version of the conda environment ( a couple of weeks ago ) and was to lazy to look into it.

Would you mind posting the errors in the thread you linked?
I have the same issue and don't have an old version of the working conda environment, this prevents me from providing PY3/QT5 builds on Win.
Another set of eyes would be greatly appreciated.
Sorry if I've hijacked the thread.

[looo]

I guess if you use a conda-build environment there will be all necessary environment variables set. At least there were no problems last time I build freecad (10 days ago). Creating an environment and building FreeCAD manually doesn't initialize all the conda-build stuff, so you have to take care on your own...

To compile freecad with conda-build in an interactive way you can do the following:

Code: Select all

conda build . -m <conda_forge_pinnings.yaml> --pyython=3.6 --keep-old-work --no-remove-work-dir

You need to extract some things from conda-build to get ide's working with the conda-build-environment. I tested this on windows and linux....

[7ofNine]

@looo: I am not using (and have no intention) to use the conda environment for building FreeCAD, this is somewhat counterproductive when using IDE (here VS). I am just trying to use it for the libraries and until recently (say mid April) this was possible and worked fine. Meanwhile I can't get past the CMAKE step. It barks about libmed and libmedc)

Check for medfile (libmed and libmedc) ...
CMake Error at C:/Program Files/CMake/share/cmake-3.11/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find MEDFile (missing: MEDFILE_INCLUDE_DIRS MEDFILE_LIBRARIES)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.11/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
cMake/FindMEDFile.cmake:54 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:746 (find_package)

These files are present in the version I am using (including cmakeConfig) but have disappeared in the recent version. The recipe for it is existing in the Gitub repository and I tried to build it from there but it failed.
I try to generate the FCad projects with nearly all bells and whistles turned on except for assembly, NETGEN, and FEM_NETGEN