Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[windows] compile dependencies (except target for x64) from source #16850

Open
wants to merge 46 commits into
base: master
from

Conversation

@Rechi
Copy link
Member

Rechi commented Oct 30, 2019

Description

build dependencies from source instead of downloading precompiled executables and libraries

test are currently failing on windows because of #16098 (comment)
uwp currently doesn't compile because of #16098 (comment)

Motivation and Context

simplify the dependency update procedure

How Has This Been Tested?

compiled Kodi for arm-windowsstore, x86-windows, x86-windowsstore and x86_64-windowsstore

Types of change

  • Bug fix (non-breaking change which fixes an issue)
  • Clean up (non-breaking change which removes non-working, unmaintained functionality)
  • Improvement (non-breaking change which improves existing functionality)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that will cause existing functionality to change)
  • Cosmetic change (non-breaking change that doesn't touch code)
  • None of the above (please explain below)

Checklist:

  • My code follows the Code Guidelines of this project
  • My change requires a change to the documentation, either Doxygen or wiki
  • I have updated the documentation accordingly
  • I have read the Contributing document
  • I have added tests to cover my change
  • All new and existing tests passed
exit 1
)

if "%Configuration%"=="Default" (

This comment has been minimized.

Copy link
@AlwinEsch

AlwinEsch Nov 3, 2019

Member

Here it check about string on all other places for debug to check empty, a special reason?
One other places it is: if "%Configuration%"=="" (

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 3, 2019

Author Member

Yes, jenkins default Configuration is Default.

@Rechi

This comment has been minimized.

Copy link
Member Author

Rechi commented Nov 3, 2019

You haven't set up git as required by the current master branch documentation and the PR branch documentation.

Git for Windows install notes

All install screens should remain at their default values with the exception of the following two.

  • Under Choosing the default editor used by Git change default to Use Notepad++ as Git's default editor or your favorite editor.
  • Under Adjust your PATH environment change default to Use Git and optional Unix tools from the Windows Command Prompt.
@AlwinEsch

This comment has been minimized.

Copy link
Member

AlwinEsch commented Nov 3, 2019

Found during first try that it wants to patch but which not available after clone and make-native-depends.bat call.

Error Output (click arrow to show):

-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.18362.
-- The CXX compiler identification is MSVC 19.16.27034.0
-- The C compiler identification is MSVC 19.16.27034.0
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Processing D:/Dev/Kodi32/xbmc/tools/windows/depends/native/common/JsonSchemaBuilder/JsonSchemaBuilder.txt
-- Processing D:/Dev/Kodi32/xbmc/tools/windows/depends/native/common/TexturePacker/TexturePacker.txt
-- TexturePacker depends: gif;jpeg-turbo;lzo2;png
-- Processing D:/Dev/Kodi32/xbmc/tools/windows/depends/native/common/flatc/flatc.txt
-- flatc url: http://mirrors.kodi.tv/build-deps/sources/flatbuffers-1.9.0.tar.gz
-- flatc extraflags: -DFLATBUFFERS_BUILD_FLATHASH:BOOL=OFF;-DFLATBUFFERS_BUILD_FLATLIB:BOOL=OFF;-DFLATBUFFERS_BUILD_TESTS:BOOL=OFF
CMake Error at D:/Dev/Kodi32/xbmc/cmake/scripts/common/HandleDepends.cmake:127 (message):
  Missing patch command (we looked in
  D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86_64-windows-native/build)
Call Stack (most recent call first):
  CMakeLists.txt:13 (add_addon_depends)

Must do a hack by copy extracted https://mirrors.kodi.tv/build-deps/win32/patch-2.7.6-bin.zip to ./tools/windows/depends/build-x86_64-windows-native/build

@AlwinEsch

This comment has been minimized.

Copy link
Member

AlwinEsch commented Nov 3, 2019

About the new required system dependency "Perl" add e.g. cmake(FATAL_ERROR "Required system dependency Perl not installed") if not present. Was before not installed and seen by generated error not direct that Perl is needed on system itself.

Error Output (click arrow to show):

  Die Erstellung von Projekt "D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build\ZERO_CHECK.vcxproj" ist abgeschlossen (Stand
  ardziele).
  Das Projekt "D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build\ALL_BUILD.vcxproj" (1) erstellt "D:\Dev\Kodi32\xbmc\tools\w
  indows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build\openssl.vcxproj" (3) auf Knoten "1" (Standardziele).
  InitializeBuildStatus:
    Aktualisieren des Timestamps von "Win32\Debug\openssl\openssl.tlog\unsuccessfulbuild".
  CustomBuild:

    Microsoft (R) Program Maintenance Utility, Version 14.16.27034.0
    Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

NMAKE : fatal error U1073: "build_generated" konnte nicht erstellt werden [D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build
\openssl.vcxproj] [D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\openssl.vcxproj]
    Stop.
  Die Erstellung des Projekts "D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build\openssl.vcxproj" ist abgeschlossen (Standar
  dziele) -- FEHLER.
  Die Erstellung des Projekts "D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build\ALL_BUILD.vcxproj" ist abgeschlossen (Stand
  ardziele) -- FEHLER.

  Fehler beim Buildvorgang.

  "D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build\ALL_BUILD.vcxproj" (Standardziel) (1) ->
  "D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build\openssl.vcxproj" (Standardziel) (3) ->
  (CustomBuild Ziel) ->
NMAKE : fatal error U1073: "build_generated" konnte nicht erstellt werden [D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\build\openssl\src\openssl-build
\openssl.vcxproj] [D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86-windows-Debug\openssl.vcxproj]

      0 Warnung(en)
      1 Fehler

@AlwinEsch

This comment has been minimized.

Copy link
Member

AlwinEsch commented Nov 3, 2019

Another part in conflict. About the Perl I has installed Strawberry, this bring a lot of own includes. Have started now build from new, where TexturePacker miss lzo/lzo1x.h.
In his CMakeCache.txt is only C:/Strawberry/c/include on all include places.

Error Output (click arrow to show):

"D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86_64-windows-native\ALL_BUILD.vcxproj" (Standardziel) (1) ->
"D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86_64-windows-native\TexturePacker.vcxproj" (Standardziel) (4) ->
(CustomBuild Ziel) ->
  D:\Dev\Kodi32\xbmc\tools\depends\native\TexturePacker\src\TexturePacker.cpp(47): fatal error C1083: Datei (Include) k
ann nicht geöffnet werden: "lzo/lzo1x.h": No such file or directory [D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86
_64-windows-native\build\TexturePacker\src\TexturePacker-build\TexturePacker\TexturePacker.vcxproj] [D:\Dev\Kodi32\xbmc
\tools\windows\depends\build-x86_64-windows-native\TexturePacker.vcxproj]
  D:\Dev\Kodi32\xbmc\tools\depends\native\TexturePacker\src\TexturePacker.cpp(47): fatal error C1083: Datei (Include) k
ann nicht geöffnet werden: "lzo/lzo1x.h": No such file or directory [D:\Dev\Kodi32\xbmc\tools\windows\depends\build-x86
_64-windows-native\build\TexturePacker\src\TexturePacker-build\TexturePacker\TexturePacker.vcxproj] [D:\Dev\Kodi32\xbmc
\tools\windows\depends\build-x86_64-windows-native\TexturePacker.vcxproj]

@Paxxi

This comment has been minimized.

Copy link
Member

Paxxi commented Nov 3, 2019

I encountered this as well. We really should specify NO_MODULE to find_package to get rid of these issues. It's the reason I spent time to make sure all our depends create and install the cmake files.

@Rechi Rechi force-pushed the Rechi:windows/depends branch from 89044d8 to d1721d7 Nov 4, 2019
@Rechi

This comment has been minimized.

Copy link
Member Author

Rechi commented Nov 4, 2019

I added find_package(Perl REQUIRED) in the OpenSSL CMakeList.txt, to get an useful error message if Perl isn't installed.

@Rechi Rechi force-pushed the Rechi:windows/depends branch from d1721d7 to 0c35bb7 Nov 4, 2019
@Rechi

This comment has been minimized.

Copy link
Member Author

Rechi commented Nov 4, 2019

@AlwinEsch @Paxxi now correct include directories should be found for TexturePacker dependencies, even if Strawberry is installed.

@afedchin

This comment has been minimized.

Copy link
Member

afedchin commented Nov 5, 2019

@Rechi easyhook hacks are required. we have to hook into a user space of gpu driver to fix issue with 24 and 60 Hz refresh rates in fse mode.

Copy link
Member

Paxxi left a comment

Overall I like it and where this is headed, great job! :)

I've added comments for x64-uwp but they're applicable to all platforms. I haven't commented or inspected the libs themselves as they can be tweaked and fixed as we go.

set NATIVE_CMAKE_GENERATOR_PLATFORM=
set NATIVE_PLATFORM=

for /f %%i in ('wmic CPU get Architecture ^| findstr "^[0-9]"') do set architecture=%%i

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

There's a system environment variable for this that can be used instead. PROCESSOR_ARCHITECTURE is set to AMD64 for 64-bit systems.

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 6, 2019

Author Member

PROCESSOR_ARCHITECTURE environment variable does not reflect the CPU architecture, it reports the architecture of the process.

This comment has been minimized.

Copy link
@driver1998

driver1998 Nov 22, 2019

If you can see PROCESSOR_ARCHITEW6432 then you are in a WoW64 process, where PROCESSOR_ARCHITEW6432 will show the native architecture.
If you can not see PROCESSOR_ARCHITEW6432, then you are in a native process.

This behavior is tested in both x64 (WoW64: x86) and ARM64 (WoW64: x86 and ARM32) platforms.


if "%architecture%"=="9" (
set NATIVE_CMAKE_GENERATOR_PLATFORM=x64
set NATIVE_PLATFORM=x86_64-windows-native

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

Can we call this x64 or x64-native? It's a lot shorter and matches the naming we use in other places such as /tools/buildsteps/windows/x64

tools/buildsteps/windows/make-native-depends.bat Outdated Show resolved Hide resolved

file(APPEND etc/fstab "${TARBALL_DIR} /var/cache/pacman/pkg\n")

install(DIRECTORY ${CMAKE_SOURCE_DIR}/

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

This install step is taking a long time. Is there a way we can speed it up? Seems to take a lot longer than the old msys2 script used to take.

tools/buildsteps/windows/make-target-depends.bat Outdated Show resolved Hide resolved

pushd %~dp0\..
call .helpers\default.bat
call vswhere.bat x64 store

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

There's no need to call vswhere.bat, cmake does all that for us.

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 6, 2019

Author Member

It was called before (bootstrap-addons.bat, BuildSetup.bat, make-addons.bat and make-mingwlibs.bat), so it still gets called

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

it was called for make-addons to have nmake available in the path, as long as we use cmake --build there should be no need to call it manually


set TARGET_CMAKE_GENERATOR=Visual Studio %vsver%
set TARGET_CMAKE_GENERATOR_PLATFORM=x64
set TARGET_CMAKE_OPTIONS=-DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=%UCRTVersion%

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

CMAKE_SYSTEM_VERSION can be set to 10.0 and cmake will take care of finding the installed sdks and set the full version.

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 6, 2019

Author Member

No, that would change behaviour.

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

change what behaviour? it already picks some version, does it matter if it's vcvarsall.bat or cmake that decides?

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 6, 2019

Author Member

No it doesn't pick a random version, at least for platforms targeting WindowsStore.

IF "%vcstore%"=="store" (
SET sdkver=10.0.17763.0

This comment has been minimized.

Copy link
@afedchin

afedchin Nov 6, 2019

Member

CMAKE_SYSTEM_VERSION=10.0 will pick up the latest installed SDK, which can break the build of dependencies such like OpenSSL

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 8, 2019

Member

ahh yeah, my bad. I guess we could give the full version we require directly to cmake instead of running vswhere.
The one benefit of vswhere I can see is that it can check for installed VS versions if we want to support both vs2017 and vs2019. We should remove the check for vs2015 from it but that's for another PR.

This comment has been minimized.

Copy link
@aronyu79

aronyu79 Nov 22, 2019

Some cmake versions (e.g. 3.13) is broken if you specify the full Windows SDK version and use the VS2019 compilers.

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 22, 2019

Author Member

Thanks for the info, but it's not relevant for now, as currently only Visual Studio 2017 is supported.

This comment has been minimized.

Copy link
@afedchin

afedchin Nov 22, 2019

Member

@aronyu79 It doesn't work for uwp only iirc

)
popd

if "%Configuration%"=="" (

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

How do we specify RelWithDebInfo build? Setting an environment variable is not intuitive and not something that's normal in Windows.

We need both RelWithDebInfo and Debug libraries for a developer setup but the toolchain file is per configuration?

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 6, 2019

Author Member

set Configuration variable to RelWithDebInfo before executing make-target-depends.bat, BuildSetup.bat and run-tests.bat.

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

make-target-depends.bat need to generate both RelWithDebInfo and Debug version of static libs, same as we provide in the prepackaged depends today.

Setting environment variables to control things is not intuitive and we should not rely on that.

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 6, 2019

Author Member

No, you decided for which configuration to build, and then build depends and Kodi with that configuration.

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 6, 2019

Member

no you generate a project and then in VS toggle between debug and RelWithDebInfo depending on what you need. It's not acceptable to have to keep two solutions depending on config.

for Jenkins it makes sense to only build RelWithDebInfo but for a developer setup both are required in the same solution.

This comment has been minimized.

Copy link
@Paxxi

Paxxi Nov 28, 2019

Member

It's a huge step backwards from what we currently have on windows so it needs to be solved before we merge this.

This comment has been minimized.

Copy link
@Rechi

Rechi Nov 30, 2019

Author Member

This will not happen, because it makes the whole process error prone and doubles the build time of target depends for no reason.

Usually one only uses the debug configuration, unless there is a very specific bug to fix which only happens in release configuration.

If two configurations get installed into the same prefix (even with different library names, which won't be picked up anyway in most cases) one variant of the include files will be overwritten and there is no guarantee that include files installed by a debug configuration are compatible with building Kodi in release configuration or the other way around.

This comment has been minimized.

Copy link
@Paxxi

Paxxi Dec 1, 2019

Member

Usually we only use RelWithDebInfo versions of dependencies because it's rare to debug the dependencies themselves and perf is better that way.

The libraries that requires both debug and release versions for Kodi to build need to be built in both configs. Also if one is working on the dependencies it needs to support building both versions from the same generated solution.

If we can't get feature parity with our current kodi-deps it's better to stay with that solution

This comment has been minimized.

Copy link
@Rechi

Rechi Dec 2, 2019

Author Member

In general one can't mix Debug and Release/RelWithDebInfo configurations. This is not a limitation of Kodi, but of Microsoft, because _ITERATOR_DEBUG_LEVEL and RuntimeLibrary mismatch.

So for building Kodi with Debug configuration you need the libraries in Debug Configuration. In that case the additional time spent for additionally building target dependencies in another configuration is just wasted.

Why does the solution have to support multiple configurations if you are working on dependencies? The reason for disabling this in general is that people just wanting to build Kodi can't get anything wrong. If you need it for whatever reason the following diff will disable the safety check, but then you are on your own.

--- a/tools/windows/depends/target/Toolchain.cmake.in
+++ b/tools/windows/depends/target/Toolchain.cmake.in
@@ -2,10 +2,4 @@ set(CMAKE_SYSTEM_NAME @CMAKE_SYSTEM_NAME@)
 set(CMAKE_SYSTEM_VERSION @CMAKE_SYSTEM_VERSION@)
 if(NOT CMAKE_PROJECT_NAME STREQUAL CMAKE_TRY_COMPILE)
-	set(CMAKE_CONFIGURATION_TYPES @CMAKE_CONFIGURATION_TYPES@)
-	if(@CMAKE_CONFIGURATION_TYPES@ STREQUAL Release)
-		list(APPEND CMAKE_CONFIGURATION_TYPES RelWithDebInfo)
-	elseif(@CMAKE_CONFIGURATION_TYPES@ STREQUAL RelWithDebInfo)
-		list(APPEND CMAKE_CONFIGURATION_TYPES Release)
-	endif()
 elseif(CMAKE_SYSTEM_NAME STREQUAL WindowsStore)
 	# try_compile command generates an executable and by default CMake generates an AppBundle for WindowsStore.

This comment has been minimized.

Copy link
@Paxxi

Paxxi Dec 3, 2019

Member

Need to test that both configs work

@Rechi Rechi force-pushed the Rechi:windows/depends branch from d342b62 to 546497c Nov 27, 2019
@Paxxi

This comment has been minimized.

Copy link
Member

Paxxi commented Dec 3, 2019

I've been thinking a lot about this PR and I thought I wanted this. After testing it I'm convinced that this is the wrong way to go. There are no real benefits in practice.
It makes the library building experience way worse not supporting multiple configs.
It makes the developer experience way worse not supporting multiple configs. This is a blocker and is a must have.
The time from cloning repo until being able to open vs and do any work is now an hour+. This is not a good experience since we're already short on windows developers.
Without multiple configs switching from debug to release means opening another vs instance and losing all context, breakpoints, bookmarks, open files etc. Worst case it also needs to build some libraries.

We still need pre-built libraries for ci machines.

There is no way that I can see this working out and there's no way I'll approve merging it.

Thank you for your work rechi, being able to try it out really helped in seeing the possible issues with the approach.

@Rechi

This comment has been minimized.

Copy link
Member Author

Rechi commented Dec 4, 2019

It makes the library building experience way worse not supporting multiple configs.

This is not Kodis fault, Microsoft doesn't let you mix Debug and Release configurations.

It makes the developer experience way worse not supporting multiple configs. This is a blocker and is a must have.

I still don't get it, usually I develop only in Debug configuration. Only in very rare cases you may need a different configuration.

The time from cloning repo until being able to open vs and do any work is now an hour+. This is not a good experience since we're already short on windows developers.

So the time needed till you can open the Kodi Visual Studio solution is more important then an easy to maintain framework for dependencies?
Also this is actually quicker then building depends for the other platforms and no one wanted precompiled dependencies for those so far.

Without multiple configs switching from debug to release means opening another vs instance and losing all context, breakpoints, bookmarks, open files etc. Worst case it also needs to build some libraries.

Yes that's right, but it's not required in the usual work flow. By the way if you switch from one target (architecture and / or platform [Windows vs WindowsStore]) you already have the same situation.

We still need pre-built libraries for ci machines.

Why?

@Paxxi

This comment has been minimized.

Copy link
Member

Paxxi commented Dec 4, 2019

It makes the library building experience way worse not supporting multiple configs.

This is not Kodis fault, Microsoft doesn't let you mix Debug and Release configurations.

We do this today so you can't blame that on Microsoft. Yes their linker errors are a pain but they don't apply to dlls and not sure if they apply to c static libraries anymore. I know c++ static libraries doesn't work with the iterator debug level error.

We've never shipped debug versions of python and it's not been an issue.

We need to have static libs built as both Debug and RelWithDebInfo but dlls only need to be built as RelWithDebInfo

It makes the developer experience way worse not supporting multiple configs. This is a blocker and is a must have.

I still don't get it, usually I develop only in Debug configuration. Only in very rare cases you may need a different configuration.

I switch to make sure things build and work in both configs, debugging issues that won't reproduce in debug etc.

The time from cloning repo until being able to open vs and do any work is now an hour+. This is not a good experience since we're already short on windows developers.

So the time needed till you can open the Kodi Visual Studio solution is more important then an easy to maintain framework for dependencies?

Yes! When I have an hour or two to look at a bug I don't want to spend that time on building libraries(This is probably somewhat personal since I'm not very active my workspace is never up to date or even cloned)

There's nothing about this that makes it easier to maintain than kodi-deps that we already have. If we wan't it in repo we can copy+paste kodi-deps into some folder and solve that issue.

Looking at https://github.com/xbmc/xbmc/commits/master/project/BuildDependencies/scripts we don't bump libraries very often so optimizing for that over daily workflow is not a good idea.

Also this is actually quicker then building depends for the other platforms and no one wanted precompiled dependencies for those so far.

I've wanted it but I don't touch Linux enough to say anything.

Without multiple configs switching from debug to release means opening another vs instance and losing all context, breakpoints, bookmarks, open files etc. Worst case it also needs to build some libraries.

Yes that's right, but it's not required in the usual work flow. By the way if you switch from one target (architecture and / or platform [Windows vs WindowsStore]) you already have the same situation.

Yes and this is annoying but afaik not something that can be solved with cmake, if we used vcxproj we could have everything in a single solution but nobody(including me) want to go back the merge conflicts and pain we had before.

We still need pre-built libraries for ci machines.

Why?

Fast feedback and not hitting time limits on travis/appveyor?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.