[cppcommon] Fix mingw gcc build

[tarc]

Specify library name and version: cppcommon/cci.20201104

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[tarc]

The patch 0003 (which set _WIN32_WINNT=_WIN32_WINNT_WIN7) is to prevent errors related to the version of the windows sdk made available by mingw gcc. For instance:

C:\XXX\.conan\data\cppcommon\cci.20201104\_\_\build\c859f3ee75fa5dd94d05d4223d7f327287b27206\source_subfolder\source\filesystem\symlink.cpp:155:73: error: 'SYMBOLIC_LINK_FLAG_DIRECTORY' was not declared in this scope
         if (!CreateSymbolicLinkW(dst.wstring().c_str(), source.c_str(), SYMBOLIC_LINK_FLAG_DIRECTORY))
                                                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

The patch 0004 (which pass the option -Wa,-mbig-obj for CYGWIN and MINGW builds) is to prevent 'too many sessions' errors.

It is worth noting that both this options are also set upstream by the project. The project, however, set this kind of things through cmake modules imported as git submodules from other repositories. So I decided to add them as patches to the main CMakeLists.txt instead.

[conan-center-bot]

Some configurations of 'cppcommon/cci.20201104' failed in build 1 (06b715376f3265220030def58c3fcae5484cb414):

• Windows x86_64, Release, Visual Studio 16, MT. Options: cppcommon:shared-False
  • Log download
  • Log error Download
  • Profile
• Access to all the logs
• Windows x86_64, Release, Visual Studio 16, MD. Options: cppcommon:shared-False
  • Log download
  • Log error Download
  • Profile
• Access to all the logs

[conan-center-bot]

All green in build 2 (3f558495466806978f6b61415b483cfc96f4e917)! 😊

• cppcommon/1.0.0.0: Generated 72 packages. All logs here
• cppcommon/cci.20201104: Generated 72 packages. All logs here

[prince-chrismc]

It is worth noting that both this options are also set upstream by the project. The project, however, set this kind of things through cmake modules imported as git submodules from other repositories. So I decided to add them as patches to the main CMakeLists.txt instead.

Please add hyperlinks to the patches so there's a trace

Perhaps there's a better way

[conan-center-bot]

All green in build 3 (2575fba18faa81bff436782db3fc23392d051536)! 😊

• cppcommon/1.0.0.0: Generated 72 packages. All logs here
• cppcommon/cci.20201104: Generated 72 packages. All logs here

[conan-center-bot]

All green in build 4 (111a4c3efb76e61d2b94cc4e6c9c46acd9a4f688)! 😊

• cppcommon/1.0.0.0: Generated 72 packages. All logs here
• cppcommon/cci.20201104: Generated 72 packages. All logs here

[tarc]

It is worth noting that both this options are also set upstream by the project. The project, however, set this kind of things through cmake modules imported as git submodules from other repositories. So I decided to add them as patches to the main CMakeLists.txt instead.

Please add hyperlinks to the patches so there's a trace

Perhaps there's a better way

The project specifies dependencies with the .gitlinks file:

cmake cmake https://github.com/chronoxor/CppCMakeScripts.git master

And imports those settings in CMakeLists.txt with:

# CMake module path
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")

# Compiler features
include(SetCompilerFeatures)
include(SetCompilerWarnings)
include(SetPlatformFeatures)
include(SystemInformation)

The settings in question are provided in SetPlatformFeatures.cmake:

if(CYGWIN)

  # Base Windows platform
  add_definitions(-DWIN32)

  # Windows 10
  add_definitions(-D_WIN32_WINNT=0x0A00)

Although it sets _WIN32_WINNT to _WIN32_WINNT_WIN10. I thought there was also a setting accounting for the -Wa,-mbig-obj thing, but I couldn't find anything. I'm removing it for now...

[conan-center-bot]

All green in build 5 (0b94b671805b88470f9b6bf31fbd776a24d98fc2)! 😊

• cppcommon/1.0.0.0: Generated 72 packages. All logs here
• cppcommon/cci.20201104: Generated 72 packages. All logs here

[prince-chrismc]

Why are the build scripts not being pulled into CCI?

I see the author is the one who invented a tool for these .gitlinks should we not just use his tool?

[tarc]

Why are the build scripts not being pulled into CCI?

I see the author is the one who invented a tool for these .gitlinks should we not just use his tool?

Well, that's something that didn't occur to me XD

The author actually focuses his GIL usage on managing dependencies - I think that's why I completelly disregarded adding it, since, err, we're using Conan... But for the sake of just getting warning settings and SDK definitions, why not??

Maybe I can try to add this GIL as a build requirement?

Do you think there's a better way to approach this, @prince-chrismc?

[tarc]

BTW, GIL is the name of the tool that manage those .gitlinks files...

[prince-chrismc]

But for the sake of just getting warning settings and SDK definitions, why not??

I agree, this approach is a bit move kill.

Do you think there's a better way to approach this, @prince-chrismc?

I think, #3903 is a source of inspiration.

I think the patches are good but they just need more commenting so that other mainters will be able to understand them and be able to re-apply them if needs be.

This author makes his work only usable to himself and it's a slippery slope to follow

[uilianries]

I see this patch as a platform/build system patch, not an hotfix based on a bug because a feature. So I'm fine accepting this patch. Of course, it would be great adding it to the upstream.