Building on Win 10 MSVS 2017 and CMake

Discuss issues related to installing or building
Post Reply
CandL
Posts: 40
Joined: Mon Oct 14 2019 6:37 pm

Building on Win 10 MSVS 2017 and CMake

Post by CandL »

First where should this discussion occur? We are making sausage here and it isn't usually pretty.

----------------------------------------------------------------------------------------------------------------------

I have modified the top level CMakeLists file to use conan to bring down OpenSSl/Zlib/Postgress.

Them I tweaked the src and network CMakeLists to include ZLIB in the include dirs

Code: Select all

if(ZLIB_FOUND)  
   if(ZLIB_INCLUDE_DIR)
    message(STATUS "setting ZLib found looking for ZLIB_INCLUDE_DIR")
	include_directories(${ZLIB_INCLUDE_DIR})
   endif(ZLIB_INCLUDE_DIR)
endif(ZLIB_FOUND)
I make a "release" dir, then cd to it.

Then my cmake line is :
cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release

Follow it up with a ninja command and get:

Code: Select all

[96/3824] Building CXX object src\core\CMakeFiles\CsCore.dir\json\qjsonvalue.cpp.obj
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\include\memory(1801): warning C4244: 'argument': conversion from 'qint64' to 'double', possible loss of data
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\include\memory(1865): note: see reference to function template instantiation 'std::_Ref_count_obj<_Ty>::_Ref_count_obj<qint64&>(qint64 &)' being compiled
        with
        [
            _Ty=QJsonDataNumber
        ]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\include\memory(1866): note: see reference to function template instantiation 'std::_Ref_count_obj<_Ty>::_Ref_count_obj<qint64&>(qint64 &)' being compiled
        with
        [
            _Ty=QJsonDataNumber
        ]
..\src\core\json\qjsonvalue.cpp(71): note: see reference to function template instantiation 'std::shared_ptr<QJsonDataNumber> std::make_shared<QJsonDataNumber,qint64&>(qint64 &)' being compiled
This is worrisome but does not stop the compile ... this however does

Code: Select all

[190/3824] Building CXX object src\core\CMakeFiles\CsCore.dir\__\3rdparty\harfbuzz\src\hb-blob.cc.obj
..\src\3rdparty\harfbuzz\src\hb-blob.cc(34): warning C4068: unknown pragma
..\src\3rdparty\harfbuzz\src\hb-blob.cc(35): warning C4068: unknown pragma
..\src\3rdparty\harfbuzz\src\hb-blob.cc(37): warning C4068: unknown pragma

[200/3824] Building CXX object src\core\CMakeFiles\CsCore.dir\__\3rdparty\harfbuzz\src\hb-ot-cff1-table.cc.obj
c:\users\210008258\github\copperspice\src\3rdparty\harfbuzz\src\hb-ot-cff-common.hh(591): warning C4138: '*/' found outside of comment
the [190] compile, makes it look like GCC Pragmas rule :)

Code: Select all

#ifndef _POSIX_C_SOURCE                                                     line 33
#pragma GCC diagnostic push                                                line 34
#pragma GCC diagnostic ignored "-Wunused-macros"               line 35
#define _POSIX_C_SOURCE 200809L
#pragma GCC diagnostic pop
#endif

Looking at hb-ot-cff-common.hh (line 591)

Code: Select all

bool sanitize (hb_sanitize_context_t *c, const void */*nullptr*/, unsigned int fdcount) const
So for 200, I am guessing the embedded comment grossed out MSVS 2017?. Removing the comment cleared the 200 error, but the 190 (Building CXX object src\core\CMakeFiles\CsCore.dir\__\3rdparty\harfbuzz\src\hb-blob.cc.obj) warning is still there.


Pushing on I see ...

Code: Select all

[200/3824] Building CXX object src\core\CMakeFiles\CsCore.dir\__\3rdparty\harfbuzz\src\hb-ot-map.cc.obj
..\src\3rdparty\harfbuzz\src\hb-ot-map.cc(243): warning C4805: '|=': unsafe mix of type 'hb_bool_t' and type 'bool' in operation
[253/3824] Building CXX object src\core\CMakeFiles\CsCore.dir\xml\qxmlstream.cpp.obj
include\QtCore\qvector.h(456): warning C4661: 'bool QVector<QXmlStreamAttribute>::removeOne(const T &)': no suitable definition provided for explicit template instantiation request
        with
        [
            T=QXmlStreamAttribute
        ]
include\QtCore\qvector.h(285): note: see declaration of 'QVector<QXmlStreamAttribute>::removeOne'
include\QtCore\qvector.h(461): warning C4661: 'bool QVector<QXmlStreamAttribute>::removeOne(const T &)': no suitable definition provided for explicit template instantiation request
        with
        [
            T=QXmlStreamAttribute
        ]
include\QtCore\qvector.h(285): note: see declaration of 'QVector<QXmlStreamAttribute>::removeOne'
include\QtCore\qvector.h(78): warning C4661: 'bool QVector<QXmlStreamAttribute>::removeOne(const T &)': no suitable definition provided for explicit template instantiation request
        with
        [
            T=QXmlStreamAttribute
        ]
include\QtCore\qvector.h(285): note: see declaration of 'QVector<QXmlStreamAttribute>::removeOne'
[254/3824] Building CXX object src\network\CMakeFiles\CsNetwork.dir\access\qabstractprotocolhandler.cpp.obj
include\QtCore\csmeta_internal_2.h(118): warning C4273: 'cs_typeName_internal<T1,void>::typeName': inconsistent dll linkage
        with
        [
            T1=QNetworkAccessManager::NetworkAccessibility
        ]
include\QtCore\csmeta.h(393): note: see previous definition of 'typeName'
include\QtCore\csmeta_internal_2.h(118): note: while compiling class template member function 'const QString &cs_typeName_internal<T1,void>::typeName(void)'
        with
        [
            T1=QNetworkAccessManager::NetworkAccessibility
        ]
include\QtCore\csmeta.h(432): note: see reference to function template instantiation 'const QString &cs_typeName_internal<T1,void>::typeName(void)' being compiled
        with
        [
            T1=QNetworkAccessManager::NetworkAccessibility
        ]
include\QtCore\csmeta.h(432): note: see reference to class template instantiation 'cs_typeName_internal<T1,void>' being compiled
        with
        [
            T1=QNetworkAccessManager::NetworkAccessibility
        ]
..\src\network\access\qnetworkaccessmanager.h(63): note: see reference to function template instantiation 'const QString &cs_typeName<QNetworkAccessManager::NetworkAccessibility>(void)' being compiled
These last messages concern me... I have to admit you have exceeded my C++ template experience. I am assuming this is what is stopping the compile. So I made it to ~250 out of 3824, this may be a while...

barbara
Posts: 172
Joined: Sat Apr 04 2015 2:32 am

Re: Building on Win 10 MSVS 2017 and CMake

Post by barbara »

I have modified the top level CMakeLists file to use conan to bring down OpenSSl/Zlib/Postgress. Them I tweaked the src and network CMakeLists to include ZLIB in the include dirs
For your first pass with CopperSpice I would strongly suggest you leave the CMake build files intact. We have tested this release in our CI and it works out of the box for our supported platforms. Once you start changing build files or code you might find errors you accidentally introduced. I know you want to use Conan and that is wonderful. But first you should have a clean build of CopperSpice.
I tweaked the src and network CMakeLists to include ZLIB in the include dirs
Again, not the best idea for right now. We test on 15 different platforms and the build files need to work everywhere and for a large number of different configurations.
Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023
I noticed this in your post and I am very curious what version of MSVC you are using. As per our CS Overview documentation our minimum supported version is "MSVC 2017 15.8.1". Earlier versions did not support enough of C++11 for things like declytype and SFINAE. We had to wait quite awhile for Microsoft to catch up and we are grateful they have.

Please have a look at our supported platforms page.
https://www.copperspice.com/docs/cs_overview/supported-platforms.html

Please make sure you have the right version of MSVC and then try again using master from github with no changes. Let's make sure you can build and then we can look at improving the CMake files and adding support for Conan. Glad to have you working with us.

Barbara

CandL
Posts: 40
Joined: Mon Oct 14 2019 6:37 pm

Re: Building on Win 10 MSVS 2017 and CMake

Post by CandL »

Will drop back to "stock" tomorrow, East Coast time here.

I have the libs installed already and will set the env vars to point to them. Just a quick new branch and will give it a go.

I will follow up with the exact MSVS 2017 version.

tim
Posts: 9
Joined: Tue Oct 15 2019 7:45 pm

Re: Building on Win 10 MSVS 2017 and CMake

Post by tim »

I think it may indeed be the version of the compiler that is used that is causing these issues. When compiling the project using GCC 9.2.0 I do not get these errors or warnings. Thank you for looking into this.

CandL
Posts: 40
Joined: Mon Oct 14 2019 6:37 pm

Re: Building on Win 10 MSVS 2017 and CMake

Post by CandL »

I have attached a console window snapshot

So MSVS 15.9.17, MSVC (cl) 19.16.27034

So dated 10/14/19 are these release notes: https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes

I have to admit being tied so tightly to compiler versions scares me.

I am a mechanical engineer ... my tools like UG NX/Catia/Ansys on Windows ALL require various versions of MSVS. And we ALWAYS trail 1-3 versions behind what is current. Sure on Linux I can hit GCC, but not on Windows.

It is not uncommon for me to have to support multiple ABIs for every lib I build...
  • 3 WINDOWS MSVS 2012/2015/2017
  • 2 Linux Gcc
  • Multiple library flags sometimes on/off
  • Release/Debug/Special
Now you see the role that conan plays for me.

So switching to C++17 just collapsed you user base to a smaller community.

Lest you think I am unique, please consider the PLEX company ( https://www.youtube.com/watch?v=wrF0Yc3n1DE notice the comment at ~22:30, Clang is MSVS ABI compliant ). Plex also uses Qt, and might be a good "customer model" for you. I do follow PLEX, and consider their operating practices quite good.

Well off try the MSVS IDE to try to follow your steps .... "precisely" ;)

Remember I normally use a console window and command line compilers so the IDE will be a challenge

CandL
Posts: 40
Joined: Mon Oct 14 2019 6:37 pm

Re: Building on Win 10 MSVS 2017 and CMake

Post by CandL »

So I just "built" 32 bit debug inside MSVS ... still prelim results, but the are tracking what I was seeing out of a CMake/Ninja build. Ninja just quit sooner.

See the snap shot below .

Is this output consistent with prior builds?

barbara
Posts: 172
Joined: Sat Apr 04 2015 2:32 am

Re: Building on Win 10 MSVS 2017 and CMake

Post by barbara »

I have to admit being tied so tightly to compiler versions scares me.
We are not forcing you to use a specific version of MSVC. We do require you use a version which is MSVC 2017 15.8.1 or newer.

This was not an arbitrary choice. We worked with the Microsoft compiler team and up until this version ( released in 2018 ) they did not conform to the C++11 standard. This was a known problem and they worked very hard to bring their compilers up to the industry standard. CopperSpice is part of their internal conformance test suite to ensure they stay compliant. Last month at CppCon 2019 we talked with a few team members and they thanked us for our contribution to MSVC.

After this release it took two other CopperSpice team members, working in close collaboration, about two months to submit changes to CS so we support MSVC. We added it to our CI in August 2018.

As a developer using C++ you should value using a compiler which actually conforms to the published ISO standard. We strongly believe having good requirements for CopperSpice is a benefit to the C++ community.
So switching to C++17 just collapsed you user base to a smaller community.
It did no such thing since this version has been out for almost four years. Our users and the C++ community value using a standard with maximum benefits. The CopperSpice team is keeping pace with C++ best practices and we communicate on a regular basis with members of the standards committee.

We also want to ensure we are compliant with pending C++20 changes. If a user of CopperSpice wants to build with C++20, this needs to work. Changes with char8_t and utf-8 string literals are going to break most string implementations. For some, this will be a major endeavor. For us it will be a few very minor changes and we can be ready well before C++20 is released.

Barbara

barbara
Posts: 172
Joined: Sat Apr 04 2015 2:32 am

Re: Building on Win 10 MSVS 2017 and CMake

Post by barbara »

So I just "built" 32 bit debug inside MSVS ... still prelim results, but the are tracking what I was seeing out of a CMake/Ninja build. Ninja just quit sooner.
No, these are not the results we have ever seen. If CopperSpice does not pass CI we do release. We are aware of warnings but we have no known blocking errors. Can you confirm that you are building CopperSpice from master on github?

Please keep in mind that we very willing to continue helping you. However, we do ask you understand that MSVC is a newer platform as of one year ago. Lets just take a step back and deal with each of your issues one at a time.

Thanks for understanding.

Barbara

CandL
Posts: 40
Joined: Mon Oct 14 2019 6:37 pm

Re: Building on Win 10 MSVS 2017 and CMake

Post by CandL »

Of course I understand... and I feel bad about posting here. But this seems to be the preferred place.

As somebody suggested before, a "slack" channel can be used to deal with these issues... leaving no residue behind :D

Once I get this built my hope is to build some sample qwt plots. But these builds are not trivial in MSVS 2017 ... a couple of hrs each.

janwilmans
Posts: 11
Joined: Wed Oct 16 2019 9:33 pm
Contact:

Re: Building on Win 10 MSVS 2017 and CMake

Post by janwilmans »

For a chat on copperspice, you can find me on #debugviewpp on the Cpplang slack. My handle is Jan(Skyhawk) there.

Post Reply