Visual Studio build configuration for Bitcoin Core

sipsorcery commented at 10:21 am on October 19, 2017: member

This PR allows Bitcoin Core to be relatively easily built with Visual Studio 2017. It’s anticipated that it could be useful for devs familiar with Visual Studio and Microsoft’s tooling. In particular the ability to use the VS debugger is a big benefit.

~~Caveats:~~

There are some minor code changes required on Bitcoin Core in order for msvc to be able to successfully compile. I’ll submit them in a separate PR, The code changes are available in #11528 #11558 and #11562.
~~The vcpkg for SECP256K1 has not yet been accepted by Microsoft. The files are available from this PR and should be copied into a vcpkg/ports/secp256k1 directory prior to vcpkg install steps.~~

Update: For anyone wishing to test out the Visual Studio build with the various open pull requests the steps are:

Clone and build Vcpkg (Microsoft’s new open source C/C++ package manager)
- git clone https://github.com/Microsoft/vcpkg
- .\bootstrap-vcpkg.bat
Set up Visual Studio to automatically reference vcpkg installs: .\vcpkg integrate install
Install the required packages (replace x86 with x64 as required):
- vcpkg install boost:x86-windows-static
- vcpkg install libevent:x86-windows-static
- vcpkg install openssl:x86-windows-static
- vcpkg install zeromq:x86-windows-static
- vcpkg install berkeleydb:x86-windows-static
- vcpkg install secp256k1:x86-windows-static
- vcpkg install leveldb:x86-windows-static
git clone https://github.com/bitcoin/bitcoin.git
git checkout -b testbuild
git pull origin pull/11526/head # Visual Studio build configuration for Bitcoin Core
~~git pull origin pull/11558/head # Minimal code changes to allow msvc compilation~~
~~git pull origin pull/11562/head # bench: use std::chrono rather than gettimeofday~~
~~Copy and unzip attached bitcoin-config.h to src/config, edit as required bitcoin-config.zip~~
~~git pull origin pull/13031/head # gmtime fix for msvc~~
Build the Visual Studio solution which, if successful, will result in all but the Qt dependent libraries/programs being built. If the build fails please add a comment.

fanquake added the label Windows on Oct 19, 2017

laanwj commented at 12:41 pm on October 19, 2017: member

Concept ACK, this is much-requested.

However IMO to be accepted upstream this needs committed maintenance, not just a one-time drop. Will you maintain this in the future when new files are added? It’s bound to break from time to time with build updates (most of us are not able to use this).

sipa commented at 12:43 pm on October 19, 2017: member

Also, is there a way to have Travis do an MSVC build? That could make sure that the configuration doesn’t bitrot.

laanwj commented at 12:49 pm on October 19, 2017: member

Also, is there a way to have Travis do an MSVC build? That could make sure that the configuration doesn’t bitrot.

Maybe. I disagree that keeping the MSVC build up to date should be required for merging anything; this would require everyone that changes things to keep MSVC up to date, which most are not able to do because they do not run that platform.

in build_msvc/README.md:33 in ca8ec95a93 outdated

28+
29+Building
30+---------------------
31+The instructions below use vcpkg to install the dependencies.
32+
33+- Clone and vcpkg from the [github repository](https://github.com/Microsoft/vcpkg) and install as per the instructions in the main README.md,

practicalswift commented at 1:12 pm on October 19, 2017:

Nit: s/,$/./

in build_msvc/README.md:16 in ca8ec95a93 outdated

13+
14+Options for installing the dependencies in a Visual Studio compatible manner are:
15+
16+- Download the source code, build each dependency, add the required include paths, link libraries and binary tools to the Visual Studio project files,
17+- Use [nuget](https://www.nuget.org/) packages with the understanding that any binary files have been compiled by an untrusted third party,
18+- Use Microsoft's [vcpkg](https://docs.microsoft.com/en-us/cpp/vcpkg) to download the source packages and build locally. This is the recommended approach.

practicalswift commented at 1:13 pm on October 19, 2017:

Nit: Start with the recommended approach.

Nit: s/,$/./ :-)

sipsorcery force-pushed on Oct 19, 2017

jonasschnelli commented at 6:41 pm on October 19, 2017: contributor

I’m not sure if we should include this in the main repository. We had similar discussions in #5276 (Xcode project). AFAIK, those “project files” tend to get outdated very fast. IMO the authors of MSVC and Xcode do not take too much care about backwards compatibility of their file formats… Also, merging this may lead to someone trying to include a CMake or XCode project.

I’d prefer an external gist/repository and maybe a link to that project (easier to remove if outdated).

sipsorcery force-pushed on Oct 19, 2017

sipsorcery force-pushed on Oct 20, 2017

meshcollider commented at 4:44 am on October 20, 2017: contributor

Hmm the whitespace lint checker is going crazy, it might need some modifications because its pretty hard to me to see what its catching here

Edit: there’s definitely some tab characters mixed up in there, maybe that’s the problem

Edit 2: Nope there’s definitely a lot of trailing whitespace too, looks like its working fine, there’s just a lot to process. Might want to do a regex find and replace to save yourself doing it manually :)

sipsorcery commented at 5:45 am on October 20, 2017: member

@MeshCollider I’m tracking down the lint failure. I’ve already removed all tabs and trimmed all end of line whitespace with sed. Looks like there’s a rule somewhere that requires certain types of files to have end of line as the last character. Will keep digging.

sipsorcery force-pushed on Oct 20, 2017

MarcoFalke commented at 7:07 am on October 20, 2017: member

@sipsorcery When saving the file in your editor, choose “Linux encoding” instead of “Windows encoding” for new lines.

sipsorcery force-pushed on Oct 20, 2017

sipsorcery commented at 7:49 am on October 20, 2017: member

No ‘\r|\t’ are in the diff patch now so hopefully lint will be happy.

If this PR does go through there will be an issue with the lint rules. In my troubleshooting I’ve discovered Visual Studio will add tab characters into a solution (.sln) file whenever it’s opened. It possibly does the same for it’s other .vcproj, .vcxproj.user and .vcxproj.filters files as well although it didn’t during my quick testing.

I could add a new rule to contrib/devtools/lint-whitespace.sh for these file types but I think I’ll leave it until a decision on this PR is made.

sipsorcery commented at 10:00 am on October 20, 2017: member

@laanwj

However IMO to be accepted upstream this needs committed maintenance, not just a one-time drop. Will you maintain this in the future when new files are added? It’s bound to break from time to time with build updates (most of us are not able to use this).

Yes.

If the VS build config gets added I will commit to maintaining it for a minimum of 3 years (end of 2020) excepting death, disability etc. As character assessment I’ve been an open source contributor since the early noughties: sourceforge, codeplex, bitbucket, github etc; no project highlights that will impress you guys but the relevant point is that I’m capable of hanging around.

I’d also expect the VS config to become popular in a short space of time which would reduce the maintenance burden.

practicalswift commented at 1:12 pm on October 20, 2017: contributor

@sipsorcery

Is there some tool to generate the vcxproj, vcxproj.filters and sln files programmatically from an easy-to-read text format that allows for easy tracking over time?

The very verbose XML build files contain a lot of duplication and random artifacts, so the same data should be possible to represent in a much more compact and human friendly way.

The following files 34 files are quite hard to reason about and/or review in detail due to the large amount of redundancy and general verbosity:

 0build_msvc/bench_bitcoin/bench_bitcoin.vcxproj
 1build_msvc/bench_bitcoin/bench_bitcoin.vcxproj.filters
 2build_msvc/bitcoin-cli/bitcoin-cli.vcxproj
 3build_msvc/bitcoin-tx/bitcoin-tx.vcxproj
 4build_msvc/bitcoin-tx/bitcoin-tx.vcxproj.filters
 5build_msvc/bitcoin.sln
 6build_msvc/bitcoind/bitcoind.vcxproj
 7build_msvc/bitcoind/bitcoind.vcxproj.filters
 8build_msvc/libbitcoin_cli/libbitcoin_cli.vcxproj
 9build_msvc/libbitcoin_cli/libbitcoin_cli.vcxproj.filters
10build_msvc/libbitcoin_common/libbitcoin_common.vcxproj
11build_msvc/libbitcoin_common/libbitcoin_common.vcxproj.filters
12build_msvc/libbitcoin_crypto/libbitcoin_crypto.vcxproj
13build_msvc/libbitcoin_crypto/libbitcoin_crypto.vcxproj.filters
14build_msvc/libbitcoin_qt/libbitcoin_qt.vcxproj
15build_msvc/libbitcoin_qt/libbitcoin_qt.vcxproj.filters
16build_msvc/libbitcoin_server/libbitcoin_server.vcxproj
17build_msvc/libbitcoin_server/libbitcoin_server.vcxproj.filters
18build_msvc/libbitcoin_util/libbitcoin_util.vcxproj
19build_msvc/libbitcoin_util/libbitcoin_util.vcxproj.filters
20build_msvc/libbitcoin_wallet/libbitcoin_wallet.vcxproj
21build_msvc/libbitcoin_wallet/libbitcoin_wallet.vcxproj.filters
22build_msvc/libbitcoin_zmq/libbitcoin_zmq.vcxproj
23build_msvc/libbitcoin_zmq/libbitcoin_zmq.vcxproj.filters
24build_msvc/libbitcoinconsensus/libbitcoinconsensus.vcxproj
25build_msvc/libleveldb/libleveldb.vcxproj
26build_msvc/libleveldb/libleveldb.vcxproj.filters
27build_msvc/libunivalue/libunivalue.vcxproj
28build_msvc/libunivalue/libunivalue.vcxproj.filters
29build_msvc/test_bitcoin-qt/test_bitcoin-qt.vcxproj
30build_msvc/test_bitcoin-qt/test_bitcoin-qt.vcxproj.filters
31build_msvc/test_bitcoin/test_bitcoin.vcxproj
32build_msvc/test_bitcoin/test_bitcoin.vcxproj.filters
33build_msvc/testconsensus/testconsensus.vcxproj

laanwj commented at 1:30 pm on October 20, 2017: member

Is there some tool to generate the vcxproj, vcxproj.filters and sln files programmatically from an easy-to-read text format that allows for easy tracking over time?

cmake can do that. Though I’m not sure about easy-to-read. Well easier to read than XML files, I guess. But I don’t think adding an indirection step makes sense unless we’d use cmake as main build system, and that’s certainly not planned and would probably piss of @theuni. These files aren’t really meant for reading, it’s just the internal configuration of a GUI program.

If the VS build config gets added I will commit to maintaining it for a minimum of 3 years (end of 2020) excepting death, disability etc. As character assessment I’ve been an open source contributor since the early noughties: sourceforge, codeplex, bitbucket, github etc; no project highlights that will impress you guys but the relevant point is that I’m capable of hanging around.

Thanks. That’s good enough for me :) You have the motiviation. You can never know for sure what happens in the future. @jonasschnelli

I’d prefer an external gist/repository and maybe a link to that project (easier to remove if outdated).

Maybe - though it’s easier for it to get lost in that case. There are AFAIK already tries at separate repositories with MSVC changes and build system, but they always get stuck at a certain version. Having it in the main repository is more of a incentive to keep it up to date. Probably.

laanwj commented at 1:35 pm on October 20, 2017: member

Maybe - though it’s easier for it to get lost in that case. There are AFAIK already tries at separate repositories with MSVC changes and build system, but they always get stuck at a certain version. Having it in the main repository is more of a incentive to keep it up to date. Probably.

If we do go that route with a separate repository, we should create an ‘official’ repository under bitcoin-core at least instead of it only existing on some user’s account.

An added advantage is that we can add @sipsorcery as committer. Delegating access is easier with separate repositories.

practicalswift commented at 1:44 pm on October 20, 2017: contributor

@laanwj I’m also thinking in terms of reproducibility. Adding 34 files to the main Bitcoin repo with a lot of redundancy (between files and within each file) that cannot be created from scratch using widely available free tools doesn’t feel quite right (almost like having some magic binary blob in the repo!) :-) I suggest we go with an approach that makes changes to the build process (read diffs) easy to reason about.

This is an approach taken by another project - a simple shell script generating the files largely from what is already in the repo: https://github.com/robotdad/vclinux/blob/master/bash/genvcxproj.sh

On the other hand if this is not part of the main repo then perhaps we can have a lower bar with regards to readability/reproducibility/understandability/reviewability :-)

laanwj commented at 1:48 pm on October 20, 2017: member

We need an approach that makes changes to the build process (read diffs) easy to reason about.

Sure, that would be good, but the primary goal here is to make it easier for windows developers to build. And having to run a bash script isn’t contributing to that.

Edit: THough we could have a generation script that is automatically run before releases, so the actual vcproj files would be part of the tarball but never the repository. Only developers using checkouts from git would then be required to run it themselves.

On the other hand if this is not part of the main repo then perhaps we can have a lower bar with regards to readability/reproducibility/understandability/reviewability :-)

Ok that would be another argument for having a separate repo.

in build_msvc/bitcoind/bitcoind.vcxproj:189 in abd142f342 outdated

184+      <Project>{5724ba7d-a09a-4ba8-800b-c4c1561b3d69}</Project>
185+    </ProjectReference>
186+  </ItemGroup>
187+  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
188+  <ImportGroup Label="ExtensionTargets">
189+    <!--<Import Label="miniupnpcTarget" Project="f:\deps\miniupnpc\miniupnpc.targets" />-->

practicalswift commented at 1:50 pm on October 20, 2017:

This can safely be removed? :-)

in build_msvc/libbitcoin_server/libbitcoin_server.vcxproj:209 in abd142f342 outdated

204+  <ItemGroup>
205+    <ClInclude Include="..\..\srcpcegister.h" />
206+  </ItemGroup>
207+  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
208+  <ImportGroup Label="ExtensionTargets">
209+    <!--<Import Label="miniupnpcTarget" Project="F:\deps\miniupnpc\miniupnpc.targets" />-->

practicalswift commented at 1:50 pm on October 20, 2017:

This can safely be removed? :-)

in build_msvc/libbitcoinconsensus/libbitcoinconsensus.vcxproj:130 in abd142f342 outdated

125+      <WarningLevel>Level3</WarningLevel>
126+      <Optimization>Disabled</Optimization>
127+      <PreprocessorDefinitions>WIN32;_DEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
128+      <SDLCheck>false</SDLCheck>
129+      <AdditionalIncludeDirectories>..\..\src;</AdditionalIncludeDirectories>
130+      <LanguageStandard>stdcpp14</LanguageStandard>

practicalswift commented at 1:54 pm on October 20, 2017:

Bitcoin is currently at C++11, so please change this instance of “stdcpp14” and the other four instances :-)

practicalswift commented at 1:59 pm on October 20, 2017: contributor

@laanwj I thought bash was widely available in Windows land these days thanks to the Windows Subsystem for Linux (WSL), but perhaps it is not yet as widely used as I thought :-)

practicalswift commented at 2:02 pm on October 20, 2017: contributor

@laanwj Good point about scripted generation that is automatically run before releases. Seems like a good solution!

sipsorcery force-pushed on Oct 20, 2017

sipsorcery commented at 9:33 pm on October 20, 2017: member

Attempting to generate the Visual Studio project files using a custom shell script will be a journey down the rabbit hole. Yes you might get a more succinct representation but maintaining the script would be a much larger burden.

The only viable approach I know of is to use cmake but even then you’ll lose some devs due to the extra steps required. And while cmake is an excellent tool it does generate a lot of redundant configuration information in its VS config.

sipsorcery force-pushed on Oct 20, 2017

NicolasDorier commented at 7:34 am on October 21, 2017: contributor

@sipsorcery this is not needed actually, you can get pretty good result by using file pattern matching in the vxproj, See https://pastebin.com/W4xmuXxy (look the ClCompile and ClInclude)

My workflow is using this csproj, and I compile through docker (shared volume with the source code). This work quite well.

I advise you to use such system, as it considerably make maintenance easier. (no need to keep in sync with bitcoin core makefile)

If there is interest to go that path, I can cleanup what I am using and commit to core.

sipsorcery commented at 9:19 am on October 21, 2017: member

@NicolasDorier my assumption was that the preference would be to match the VS projects to the existing makefiles but that’s probably not a particularly strong reason.

There are pros and cons to multiple projects compared to a single, or fewer, larger ones. And if you wanted all the .exe applications (bench_bitcoin, bitcoin-cli, bitcoind, bitcoin-tx, test_bitcoin) you’d still need a separate project. And at a minimum I’d recommend the Qt related source files be excluded as since when the pre-processsing steps (protoc, bincc, moc, uic, lrelease) are invoked it can take a looong time.

I think the following projects “could” be safely consolidated if people thought it was a good idea:

libunivalue
libleveldb
libbitcoin_zmp
libbitcoinwallet
libbitcoin_util
libbitcoin_server
libbitcoin_crypto
libbitcoin_common
libbitcoin_cli

My vote is for a modular approach that mirrors the existing makefiles. Ultimately though I’d be happy with any VS build config in the bitcoin or bitcoin-core repos that empowers us poor MS devs with our emancipated command line skills.

I will go ahead and remove the .vcxproj.filters files as they are only used to layout the source files in each project and given the concerns about verbosity can safely be omitted.

NicolasDorier commented at 9:25 am on October 21, 2017: contributor

I am neutral on this. I only tried C++ dev with the vcxproj using wildcard. With this you can see instantly any error, pretty good auto completion, and good indexation of symbols for fast browsing which is all I ask for. I will try your way, maybe it is better.

Btw, VS2017 support GDB debugging on linux. There might even be a way for us to get the interactive debugging inside VS. (out of scope now though)

sipsorcery force-pushed on Oct 21, 2017

theuni commented at 8:24 pm on October 24, 2017: member

@laanwj I’m certainly not opposed to a different build-system if something better comes along. I’ve never liked CMake, but it’s been years since I last messed with it, maybe it’s improved since then.

That said, for the time being, a separate repo sounds good to me. It’s also a good way to gauge the demand.

ryanofsky commented at 9:03 pm on October 24, 2017: member

@sipsorcery, how are you getting Visual Studio to pick up the dependencies? When I checked out this PR, merged #11528, “vcpkg install"ed all the packages mentioned in the readme, ran “vcpkg integrate install”, and tried to build the solution in visual studio, I got hundreds of include and link errors. Right clicking individual project properties and manually adding “C:\users\russ\src\vcpkg\installed\x86-windows\include” and “C:\Users\russ\src\bitcoin\src\secp256k1\include” (just for secp256k1_recovery.h) include directories, “C:\Users\russ\src\vcpkg\installed\x86-windows\lib” library directory, and “boost_date_time-vc140-mt-1_65_1.lib;boost_filesystem-vc140-mt-1_65_1.lib;boost_system-vc140-mt-1_65_1.lib” additional dependencies fixed a lot of errors, but there are still hundreds more.

Is there a bug here, or some step I’m missing?

sipsorcery commented at 9:39 pm on October 24, 2017: member

@ryanofsky did you restart Visual Studio after running the “vcpkg integrate install” and after all the vcpkg packages were installed? The way vcpkg works is to automatically import additional targets to each project when Visual Studio starts up. It should all be seamless, no need for adding libraries or directories.

If you’re still getting missing dependencies and includes then there is definitely something up between Visual Studio and vcpkg. Check your vcpkg/installed/x86-windows-static directory to double check that each of the dependencies was correctly installed.

ryanofsky commented at 10:09 pm on October 24, 2017: member

@ryanofsky did you restart Visual Studio after running the “vcpkg integrate install” and after all the vcpkg packages were installed? The way vcpkg works is to automatically import additional targets to each project when Visual Studio starts up.

Thanks for the explanation! I restarted and now I see cl /c /I..\..\src /I"C:\Users\russ\src\vcpkg\installed\x64-windows-static\include"… in the build output. I think the problem is that I installed the x86 libraries instead of x64 ones. Waiting for those to build now :)

NicolasDorier commented at 2:41 am on October 25, 2017: contributor

@sipsorcery I missed that you said " relatively easily built with Visual Studio 2017", my solution only allow editing (build still on linux) and is thus not as good as this PR. Will give a try.

sipsorcery commented at 3:48 am on October 25, 2017: member

Just in case there’s any confusion, this PR isn’t intended as a replacement for any of the existing Bitcoin autoconf/make build mechanisms. Instead it’s intended to save other devs who are interested in using Visual Studio, for whatever their own reasons, the time and effort of wrangling the bitcoin source and dependencies. It might not look like it but close to 3-4 weeks of full time work to get to this point. Admittedly probably half that time was spent on Qt5 related work and another big chunk on wrong turns managing dependencies, such as nuget. @theuni no alternative is being proposed, this PR is about adding another option. CMake isn’t part of the VS/Microsoft tool chain and is not part of this PR (Update: except where it is used by the vcpkg tool for dependency acquisition).

ryanofsky commented at 6:22 pm on October 25, 2017: member

Conditional ACK a38801c5b3bfc72a41ccbd6328c81aa10a0dca51. The project files are working for me, but could use a few changes and fixes:

I think the project files should be added to main repository, but under a contrib/build-msvc/ directory instead of the top level build_msvc/ because they are significant contribution that can save windows developers who want to work with bitcoin a lot of time, headaches, and effort, but are also something we need to be able to easily drop in case they stop being maintained, or become more of a burden to maintain than we are anticipating.
I needed to add ..\..\src\secp256k1\include to “additional include directories” for the libbitcoin_{common,server,wallet} projects in order for them to be able to find secp256k1_recovery.h, which is part of the vcpkg secp256k1 build tree, but does not seem to get installed. (The only secp file in C:\Users\russ\src\vcpkg\installed\x64-windows-static\include is secp256k1.h.) Maybe it would be better to just use the included secp sources instead of relying on the vcpkg package. That’s what this PR is already doing for univalue and leveldb.
It might make sense to drop the libbitcoin_qt project for now since it doesn’t seem to be working yet.
The test_bitcoin and bench_bitcoin projects which rely on generated files aren’t currently working for me. Errors look like:

03>------ Build started: Project: bench_bitcoin, Configuration: Debug x64 ------
13>checkblock.cpp
23>c:\users\russ\src\bitcoin\src\bench\checkblock.cpp(13): fatal error C1083: Cannot open include file: 'bench/data/block413567.raw.h': No such file or directory
33>Done building project "bench_bitcoin.vcxproj" -- FAILED.

 03>------ Build started: Project: test_bitcoin, Configuration: Debug x64 ------
 13>transaction_tests.cpp
 23>c:\users\russ\src\bitcoin\src\test\transaction_tests.cpp(5): fatal error C1083: Cannot open include file: 'data/tx_invalid.json.h': No such file or directory
 33>sighash_tests.cpp
 43>c:\users\russ\src\bitcoin\src\test\sighash_tests.cpp(7): fatal error C1083: Cannot open include file: 'data/sighash.json.h': No such file or directory
 53>script_tests.cpp
 63>c:\users\russ\src\bitcoin\src\test\script_tests.cpp(5): fatal error C1083: Cannot open include file: 'data/script_tests.json.h': No such file or directory
 73>base58_tests.cpp
 83>c:\users\russ\src\bitcoin\src\test\base58_tests.cpp(7): fatal error C1083: Cannot open include file: 'data/base58_encode_decode.json.h': No such file or directory
 93>Generating Code...
103>Done building project "test_bitcoin.vcxproj" -- FAILED.
11========== Build: 2 succeeded, 1 failed, 8 up-to-date, 0 skipped ==========

Other notes:

There are tons of compiler warnings, mostly about implicit integer conversions in serialization code which would be nice to fix separately.
I suspect maintaining a CMakeLists.txt file (if someone wanted to step up and write one) would probably be easier than maintaining all these xml project defintions. The community edition version of visual studio I downloaded has an option to explicitly open cmake files, so it doesn’t seem to be true that using CMake would add an extra step the visual studio build process. I have a lot of experience with CMake on unix, and my overall impression is that while the CMake language, primitives, and workflow are gratuitously weird, they do work really well in practice.

sipsorcery commented at 10:11 pm on October 25, 2017: member

@ryanofsky thanks for testing out the PR.

I did originally have the project files in contrib/build-msvc but moved them based on the way precedent in BerkeleyDB. If necessary they can be moved to wherever the consensus decides.
Thanks for the note on the missing secp256k1 headers. That’s a problem with the vcpkg I created for it. I’ve fixed and submitted the PR to Microsoft.
libbitcoin_qt does build but requires the Qt5 dependency set up correctly. The vcpkg Qt5 package currently doesn’t support static builds. Like anything with Qt it will take a lot of time and effort to wrangle so in this case, and assuming this PR goes ahead, stage 2 will be to document/package the Qt5 dependency.
I’d overlooked the pre-generated files for the test and bench projects. I must have copied them straight across from the mingw build. Will look into those shortly.
Maintaining CMake files would be more effort than maintaining the VS files. It would make sense if the CMake config was being used to generate other build configs but this PR is only concerned about VS. A substantial portion of Windows devs don’t tend to use the *nix tool chains and aren’t familiar with CMake etc. and a straight VS config will make life easier for them.

sipsorcery force-pushed on Oct 30, 2017

sipsorcery commented at 8:41 pm on October 30, 2017: member

@ryanofsky with the latest change the missing auto-generated headers should now be fixed. I’d be interested to know if you can build without tweaks now?

I ended up having to add a new project to replicate the *nix hexdump utility. I spent a day trying to integrate Visual Studio with different permutations of powershell scripts, piping to WSL and various Windows hexdump ports, but all had shortcomings. It does mean the config now contains a small C++ program but that’s the simplest alternative I could come up with.

sipsorcery force-pushed on Oct 31, 2017

NicolasDorier commented at 7:41 pm on October 31, 2017: contributor

@sipsorcery msbuild supports inline C# tasks, might be good alternative to C++ prog.

sipsorcery force-pushed on Nov 1, 2017

sipsorcery commented at 9:51 am on November 1, 2017: member

@NicolasDorier an inline task for the hexdump header generation is a much better approach. I’ve switched the VS config to it.

carlton355 commented at 2:15 pm on November 1, 2017: none

I was able to build this with no errors by following your steps.

donaloconnor commented at 8:40 pm on November 1, 2017: contributor

@sipsorcery - Thanks for this effort. I was able to successfully build (x64 configuration) with VS 2017 (Community).

As mentioned earlier, there are an incredible amount of warnings. I might work on a separate PR to fix these.

BTW, is it necessary that we target building with the Windows 10 fall creators upgrade SDK? It would be good if we could drop this requirement back to maybe Win7?

sipsorcery commented at 9:11 pm on November 1, 2017: member

@donaloconnor thx for testing. As far as the target Windows SDK version I believe Visual Studio will revert to its default if what’s specified in the project file is not available but I’m not 100% on that. Apart from that it’s trivial to retarget to a different Windows SDK, in the Solution Explorer pane right click the Solution->Retarget solution and then select the desired SDK version. That updates the SDK version for all projects and configurations in the solution in a couple of clicks.

sipsorcery force-pushed on Nov 17, 2017

sipsorcery force-pushed on Nov 19, 2017

NicolasDorier commented at 6:50 am on November 20, 2017: contributor

Just to note: @sipsorcery made a dockerfile based on windowsservercore internally in our company. It can be eventually used for easily Bitcoin CI on AppVeyor for native Windows builds. (AppVeyor is Travis equivalent for Windows world)

Might be useful (in separate PR?) to share that later.

laanwj commented at 8:37 am on November 20, 2017: member

Might be useful (in separate PR?) to share that later.

Regularly running the tests with a completely different compiler/platform would be really nice (but indeed, something for a future PR).

MarcoFalke commented at 7:51 pm on November 22, 2017: member

Jup, that would be useful. Reminds me of #8227

huhorler commented at 9:29 am on December 13, 2017: none

D:\bitcoin\build_msvc\libbitcoin_qt\libbitcoin_qt.vcxproj(923,5): error MSB3073: command “\bin\moc.exe “....\src\qt\addressbookpage.h” -o .\GeneratedFiles\moc_addressbookpage.cpp How to build the qt proj.

sipsorcery commented at 10:09 am on December 13, 2017: member

@huhorler accomplishing a static build of Qt on Windows is a major feat. It took me 4 days. If you can get Qt built then building the two bitcoin Qt dependent apps is relatively straight forward.

If you do decide to give it a shot here are the config script parameters I used (you’ll need to adjust the paths):

..\configure -prefix F:\deps\qt\5.9.2-static-ssl\vc141-x86\ -platform win32-msvc -debug-and-release -opensource -confirm-license -strip -no-shared -static -no-static-runtime -ltcg -make libs -make tools -nomake examples -no-compile-examples -no-dbus -no-qml-debug -no-icu -no-gtk -no-opengl -no-opengles3 -no-angle -no-sql-sqlite -no-sql-odbc -no-sqlite -skip qt3d -skip qtactiveqt -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtdeclarative -skip qtdoc -skip qtgamepad -skip qtgraphicaleffects -skip qtimageformats -skip qtlocation -skip qtmacextras -skip qtmultimedia -skip qtnetworkauth -skip qtpurchasing -skip qtquickcontrols -skip qtquickcontrols2 -skip qtscript -skip qtscxml -skip qtsensors -skip qtserialbus -skip qtserialport -skip qtspeech -skip qtvirtualkeyboard -skip qtwayland -skip qtwebchannel -skip qtwebengine -skip qtwebsockets -skip qtwebview -skip qtx11extras -skip qtxmlpatterns -recheck-all -ssl -openssl-linked -IF:\deps\openssl\1.0.2\vc141-x86\include -LF:\deps\openssl\1.0.2\vc141-x86\lib OPENSSL_LIBS_RELEASE="-llibeay32 -lssleay32 -lgdi32 -luser32 -lwsock32 -ladvapi32" OPENSSL_LIBS_DEBUG="-llibeay32d -lssleay32d -lgdi32 -luser32 -lwsock32 -ladvapi32"

vinniefalco commented at 6:53 pm on December 23, 2017: contributor

I followed the directions and failed to build using Visual Studio Community edition. The error:

01>c:\users\vinnie\src\bitcoin\src\random.h(131): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
11>c:\users\vinnie\src\bitcoin\src\random.h(131): error C2146: syntax error: missing ';' before identifier 'NUM_OS_RANDOM_BYTES'

I see no place that defines NUM_OS_RANDOM_BYTES.

sipsorcery commented at 8:46 am on December 24, 2017: member

@vinniefalco do you need to pull the master branch to get the latest updates? That constant is defined in random.h.

vinniefalco commented at 1:53 pm on December 24, 2017: contributor

I’ll try that. Note that the instructions in the pull request indicate to use the testbuild branch:

0git checkout -b testbuild

sipsorcery force-pushed on Jan 30, 2018

sipsorcery force-pushed on Mar 2, 2018

in build_msvc/README.md:44 in 4829718464 outdated

39+    - vcpkg install libevent:x86-windows-static
40+    - vcpkg install openssl:x86-windows-static
41+    - vcpkg install zeromq:x86-windows-static
42+    - vcpkg install berkeleydb:x86-windows-static
43+    - vcpkg install secp256k1:x86-windows-static
44+    - vcpkg install leveldb:x86-windows-static

NicolasDorier commented at 6:11 pm on March 4, 2018:

nit: should advise to use Powershell and install everything in one command

0.\vcpkg install `
1boost:x86-windows-static `
2libevent:x86-windows-static `
3openssl:x86-windows-static `
4zeromq:x86-windows-static `
5berkeleydb:x86-windows-static `
6secp256k1:x86-windows-static  `
7leveldb:x86-windows-static

sipsorcery commented at 11:27 pm on March 4, 2018:

Good idea, modified.

sipsorcery force-pushed on Mar 4, 2018

NicolasDorier commented at 3:38 pm on March 5, 2018: contributor

bench_bitcoin.exe seems to crash, investigating…

NicolasDorier commented at 9:07 pm on March 5, 2018: contributor

@sipsorcery I manage to build on visual studio but somehow command line by using msbuild seems to unable to find vcpkg headers.

NicolasDorier commented at 9:32 pm on March 5, 2018: contributor

@sipsorcery I made

https://github.com/NicolasDorier/bitcoin/commit/b19dcc186a80d076c992a16c4b2731fef46e9f20

It automatically copy the bitcoin-config as part of the build process. It also make it possible to build on Win10 without retargeting the projects.

The use of common project file will allow us later to generate the bitcoin-config.h (via cmake which has support from VS2017) instead of simply copying without having to change the code all over the place.

NicolasDorier commented at 10:58 pm on March 5, 2018: contributor

So the crashes on bench_bitcoin are due to assert statement being stripped by msvc.

So question is, should we keep

0assert(stream.Rewind(sizeof(block_bench::block413567)));

and make sure msvc does not remove assert. Or should we make sure that no side-effect stuff is done in assert?

sipsorcery commented at 11:27 pm on March 5, 2018: member

@NicolasDorier common project file to generate bitcoin-config.h is a good idea. Is it worth adding it to this PR?

I get the same crash in bench_bitcoin. I’d also agree with you that it would be better to do the stream.Rewind (and other side effect operations) outside of the assert. I would think the asserts should solely be used to test conditions.

NicolasDorier commented at 2:16 am on March 6, 2018: contributor

@sipsorcery no need to generate the config to this PR, this can come later, I included the bitcoin-config.h in the build process so there is no need to document it + ship the .h in a separate zip file outside of git versioning. (can you cherry pick https://github.com/NicolasDorier/bitcoin/commit/b19dcc186a80d076c992a16c4b2731fef46e9f20 ?)

NicolasDorier commented at 12:38 pm on March 6, 2018: contributor

Added to https://github.com/NicolasDorier/bitcoin/commits/testbuildnico

Build without retargetting on Windows 10
Remove the manual step of copying the config-bitcoin.h
Ignore vcxproj.user files (User specific settings for the project in VS)
Remove NDEBUG in release for test stuff so assert with side effect do not get stripped

bench_bitcoin.exe is now running properly, test_bitcoin.exe is passing fine.

NicolasDorier commented at 6:17 pm on March 6, 2018: contributor

I updated my branch

Now properly compiling by using MSBuild (the build error via msbuild command line was that for some reason the Plateform property was not set by default to Win32)

NicolasDorier commented at 6:38 pm on March 6, 2018: contributor

So I ran a bench_bitcoin between the msvc version and the cross compiled for windows version. It is order of magnitude difference. MSVC version is very very slow for some reason… investigating.

donaloconnor commented at 6:44 pm on March 6, 2018: contributor

So I ran a bench_bitcoin between the msvc version and the cross compiled for windows version. It is order of magnitude difference. MSVC version is very very slow for some reason… investigating.

Are you compiling a release build and detached from the debugger when running the tests? (If the debugger is attached, a special (slower) debug heap is used.

NicolasDorier commented at 6:51 pm on March 6, 2018: contributor

Update: My bad I was on a very old commit actually… retrying.

Yes, but I think the problem is different, the output of bench_bitcoin seems to be based on different version. I am trying to rebase.

NicolasDorier commented at 7:49 pm on March 6, 2018: contributor

Benchmark result based on f13d756cdd9445d1478a70c5387df2a444045f6e

Using MSVC:

 0# Benchmark, evals, iterations, total, min, max, median
 1Base58CheckEncode, 5, 320000, 9.58107, 5.94158e-06, 6.04325e-06, 6.00087e-06
 2Base58Decode, 5, 800000, 6.66596, 1.65218e-06, 1.69618e-06, 1.6645e-06
 3Base58Encode, 5, 470000, 8.9089, 3.76216e-06, 3.82214e-06, 3.78687e-06
 4BenchLockedPool, 5, 530, 7.63946, 0.00281322, 0.00294693, 0.00287078
 5CCheckQueueSpeedPrevectorJob, 5, 1400, 7.84402, 0.00109194, 0.00113575, 0.00112266
 6CCoinsCaching, 5, 170000, 10.7337, 1.23969e-05, 1.28584e-05, 
 7CoinSelection, 5, 650, 10.4217, 0.00311061, 0.00332764, 0.00322123
 8DeserializeAndCheckBlockTest, 5, 160, 11.5849, 0.0142856, 0.0148326, 0.0143983
 9DeserializeBlockTest, 5, 130, 7.29183, 0.0110195, 0.0114873, 0.0111978
10FastRandom_1bit, 5, 440000000, 26.4041, 1.1693e-08, 1.28368e-08, 1.1765e-08
11FastRandom_32bit, 5, 110000000, 12.1345, 2.18753e-08, 2.24223e-08, 2.19454e-08
12MempoolEviction, 5, 41000, 16.0266, 7.53468e-05, 8.64916e-05, 7.64021e-05
13RIPEMD160, 5, 440, 10.3656, 0.00442749, 0.0050962, 0.00458359
14RollingBloom, 5, 1500000, 6.84173, 8.82562e-07, 9.38626e-07, 9.25587e-07
15SHA1, 5, 570, 7.72847, 0.00268478, 0.00275603, 0.00269575
16SHA256, 5, 340, 12.3184, 0.00652333, 0.00872471, 0.0070202
17SHA256_32b, 5, 4700000, 11.377, 4.8046e-07, 4.85879e-07, 4.8528e-07
18SHA512, 5, 330, 27.845, 0.0163766, 0.0186157, 0.0164709
19SipHash_32b, 5, 40000000, 30.5322, 1.5218e-07, 1.53116e-07, 1.52675e-07
20Sleep100ms, 5, 10, 5.05761, 0.100789, 0.101583, 0.101268
21Trig, 5, 12000000, 1.5014, 2.47625e-08, 2.53812e-08, 2.49326e-08
22VerifyScriptBench, 5, 6300, 29.5021, 0.00090531, 0.00101466, 0.000921225

Using MINGW32:

 0# Benchmark, evals, iterations, total, min, max, median
 1Base58CheckEncode, 5, 320000, 7.91675, 4.91435e-006, 4.96565e-006, 4.9587e-006
 2Base58Decode, 5, 800000, 8.24757, 2.02399e-006, 2.08952e-006, 2.06045e-006
 3Base58Encode, 5, 470000, 8.01109, 3.20622e-006, 3.62817e-006, 3.4371e-006
 4BenchLockedPool, 5, 530, 8.55124, 0.0031643, 0.00328073, 0.0032388
 5CCheckQueueSpeedPrevectorJob, 5, 1400, 10.3193, 0.00146465, 0.00148749, 0.00147139
 6CCoinsCaching, 5, 170000, 9.52761, 1.10014e-005, 1.14885e-005, 1.11721e-005
 7CoinSelection, 5, 650, 18.3554, 0.00542891, 0.00607096, 0.00551345
 8DeserializeAndCheckBlockTest, 5, 160, 10.5187, 0.0130217, 0.0133201, 0.013142
 9DeserializeBlockTest, 5, 130, 7.36567, 0.0108283, 0.0123782, 0.0111937
10FastRandom_1bit, 5, 440000000, 4.80039, 2.14043e-009, 2.24242e-009, 2.17553e-009
11FastRandom_32bit, 5, 110000000, 6.40718, 1.13598e-008, 1.19127e-008, 1.16302e-008
12MempoolEviction, 5, 41000, 21.7848, 0.000105057, 0.00010777, 0.000105685
13PrevectorClearNontrivial, 5, 28300, 4.86739, 3.31913e-005, 3.54666e-005, 3.44578e-005
14PrevectorClearTrivial, 5, 88600, 8.6593, 1.80437e-005, 2.21844e-005, 1.88127e-005
15PrevectorDestructorNontrivial, 5, 28800, 6.74105, 4.17441e-005, 5.38027e-005, 4.52309e-005
16PrevectorDestructorTrivial, 5, 88900, 7.82589, 1.6831e-005, 1.95849e-005, 1.71143e-005
17PrevectorResizeNontrivial, 5, 28900, 4.98257, 3.40239e-005, 3.49015e-005, 3.44035e-005
18PrevectorResizeTrivial, 5, 90300, 7.74884, 1.6991e-005, 1.73386e-005, 1.71626e-005
19RIPEMD160, 5, 440, 7.00343, 0.00311329, 0.003257, 0.00319395
20RollingBloom, 5, 1500000, 7.69936, 9.85285e-007, 1.08814e-006, 1.00516e-006
21SHA1, 5, 570, 8.3434, 0.00281848, 0.00313455, 0.00290756
22SHA256, 5, 340, 6.63042, 0.00379251, 0.00395742, 0.00391406
23SHA256_32b, 5, 4700000, 6.84698, 2.87698e-007, 2.94654e-007, 2.91159e-007
24SHA512, 5, 330, 5.84944, 0.00349496, 0.00357262, 0.00355178
25SipHash_32b, 5, 40000000, 8.00846, 3.93307e-008, 4.05576e-008, 4.01336e-008
26Sleep100ms, 5, 10, 5.05227, 0.100605, 0.10172, 0.101045
27Trig, 5, 12000000, 3.2378, 5.30155e-008, 5.51471e-008, 5.37461e-008
28VerifyScriptBench, 5, 6300, 6.82862, 0.000201415, 0.000229147, 0.000216088

Conclusion:

Result similar enough, VerifyScriptBench is 4 to 5 times slower on msvc.

sipsorcery force-pushed on Mar 7, 2018

sipsorcery commented at 3:52 am on March 7, 2018: member

@NicolasDorier I’ve updated my PR to use your two the common and common.init project files. The whole thing now builds correctly on AppVeyor without the need for the manual bitcoin-config.h copy step.

On my machine Visual Studio states that I don’t have the correct SDK version installed (which could be true, I haven’t looked into it yet). An my workaround was to put the specific version in common.init.vcxproj:

<WindowsTargetPlatformVersion>10.0.15063.0</WindowsTargetPlatformVersion>

Since the AppVeyor build works I’m assuming this is an issue with my machine.

NicolasDorier commented at 1:35 pm on March 7, 2018: contributor

@sipsorcery normally this https://github.com/sipsorcery/bitcoin/blob/90ffa797c1e1a02bd450329f15955fdfc360542b/build_msvc/common.init.vcxproj is auto detecting the WindowsTargetPlatformVersion. Can you take a look if the registry is right?

What about running msbuild in command line? same error?

NicolasDorier commented at 1:37 pm on March 7, 2018: contributor

@sipsorcery can you keep the commits as in https://github.com/NicolasDorier/bitcoin/commits/testbuildnico ? We can squash later, it is better for review. I see you forgot some of my commits.

sipsorcery force-pushed on Mar 7, 2018

sipsorcery commented at 0:28 am on March 8, 2018: member

@NicolasDorier updating Visual Studio fixed my platform version problem and msbuild also works fine.

NicolasDorier commented at 4:45 am on March 8, 2018: contributor

@sipsorcery shit I would have know why you had this problem before updating. :(

sipsorcery force-pushed on Mar 8, 2018

sipsorcery force-pushed on Mar 14, 2018

MarcoFalke commented at 8:21 pm on April 11, 2018: member

Has anyone had success testing this according to the steps given in the OP?

ryanofsky commented at 9:20 pm on April 11, 2018: member

Has anyone had success testing this according to the steps given in the OP?

It’s been a while, but this was working for me when I tried it last: #11526 (comment)

sipsorcery commented at 11:01 pm on April 11, 2018: member

@MarcoFalke this appveyor job runs the same steps.

The build breaks roughly once or twice a month when a source file gets deleted, renamed or created. I then fix it when I get a chance (at the time of writing it has been broken for the last 4 days and I’ve just fixed it now).

in build_msvc/README.md:45 in 5fc0e252bc outdated

40+ libevent:x64-windows-static `
41+ openssl:x64-windows-static `
42+ zeromq:x64-windows-static `
43+ berkeleydb:x64-windows-static `
44+ secp256k1:x64-windows-static `
45+ leveldb:x64-windows-static

MarcoFalke commented at 11:02 pm on April 11, 2018:

The backticks don’t display well for me. I think you can prepend some (4) spaces to fix it:

0    PS >.\vcpkg install `
1    boost:x64-windows-static `
2    libevent:x64-windows-static `
3    openssl:x64-windows-static `
4    zeromq:x64-windows-static `
5    berkeleydb:x64-windows-static `
6    secp256k1:x64-windows-static `
7    leveldb:x64-windows-static

MarcoFalke commented at 11:22 pm on April 11, 2018:

@sipsorcery Needs to be exactly 4 spaces, I think.

in build_msvc/bitcoin-config.h:36 in 5fc0e252bc outdated

31+
32+/* Replacement for %s in copyright holders string */
33+#define COPYRIGHT_HOLDERS_SUBSTITUTION "Bitcoin Core"
34+
35+/* Copyright year */
36+#define COPYRIGHT_YEAR 2017

MarcoFalke commented at 11:05 pm on April 11, 2018:

The version above and this year seem to be outdated.

Is it required to have this file checked in? If so, please update. Otherwise remove ;)

in build_msvc/bitcoin-config.h:362 in 5fc0e252bc outdated

357+
358+/* Define to the home page for this package. */
359+#define PACKAGE_URL "https://bitcoincore.org/"
360+
361+/* Define to the version of this package. */
362+#define PACKAGE_VERSION "0.15.99"

MarcoFalke commented at 11:06 pm on April 11, 2018:

Same here and 9 lines above

MarcoFalke commented at 11:10 pm on April 11, 2018: member

utACK 5fc0e252bcc2348f158cd5ccd7d332aaffdd4531 beside nits

sipsorcery force-pushed on Apr 11, 2018

in build_msvc/bitcoin-config.h:6 in ec9f115aed outdated

0@@ -0,0 +1,428 @@
1+/* src/config/bitcoin-config.h.  Generated from bitcoin-config.h.in by configure.  */
2+/* src/config/bitcoin-config.h.in.  Generated from configure.ac by autoheader.  */
3+
4+#ifndef BITCOIN_CONFIG_H
5+
6+#define BITCOIN_CONFIG_H

MarcoFalke commented at 11:37 pm on April 11, 2018:

You might have to update the linter to avoid spurious warnings:

 0diff --git a/contrib/devtools/lint-include-guards.sh b/contrib/devtools/lint-include-guards.sh
 1index 6a0dd556bb..d9cf8effee 100755
 2--- a/contrib/devtools/lint-include-guards.sh
 3+++ b/contrib/devtools/lint-include-guards.sh
 4@@ -9,7 +9,7 @@
 5 HEADER_ID_PREFIX="BITCOIN_"
 6 HEADER_ID_SUFFIX="_H"
 7 
 8-REGEXP_EXCLUDE_FILES_WITH_PREFIX="src/(crypto/ctaes/|leveldb/|secp256k1/|tinyformat.h|univalue/)"
 9+REGEXP_EXCLUDE_FILES_WITH_PREFIX="(build_msvc/|src/(crypto/ctaes/|leveldb/|secp256k1/|tinyformat.h|univalue/))"
10 
11 EXIT_CODE=0
12 for HEADER_FILE in $(git ls-files -- "*.h" | grep -vE "^${REGEXP_EXCLUDE_FILES_WITH_PREFIX}")

Warning was:

0build_msvc/bitcoin-config.h seems to be missing the expected include guard:
1  #ifndef BITCOIN_BITCOIN-CONFIG_H
2  #define BITCOIN_BITCOIN-CONFIG_H
3  ...
4  #endif // BITCOIN_BITCOIN-CONFIG_H
5^---- failure generated from contrib/devtools/lint-include-guards.sh

MarcoFalke commented at 11:47 pm on April 11, 2018: member

re-utACK fcc8dcb. Thanks for addressing the nits

MarcoFalke commented at 0:23 am on April 12, 2018: member

@sipsorcery Don’t worry about the include guard. See #12956

sipsorcery commented at 1:23 am on April 12, 2018: member

@MarcoFalke the lint parser still catches that header as it’s in the build_msvc directory.

REGEXP_EXCLUDE_FILES_WITH_PREFIX="src/(crypto/ctaes/|leveldb/|secp256k1/|tinyformat.h|univalue/)"

I’ll find a way to workaround it.

sipsorcery force-pushed on Apr 27, 2018

sipsorcery force-pushed on Jun 13, 2018

sipsorcery force-pushed on Jul 16, 2018

sipsorcery force-pushed on Jul 25, 2018

ken2812221 commented at 3:06 am on August 8, 2018: contributor

Installing the following boost packages should be enough instead of all boost packages:

boost-filesystem
boost-signals2
boost-interprocess
boost-test

MarcoFalke renamed this:
~~Visual Studio build configuration for Bitcoin Core.~~
Visual Studio build configuration for Bitcoin Core
on Aug 8, 2018

MarcoFalke commented at 1:10 pm on August 8, 2018: member

Could you please squash the commits a bit to get rid of the intermediate merge commit? For example something like this:

0git fetch upstream
1git merge upstream/master
2git reset --soft upstream/master
3git commit -m "Visual Studio build configuration for Bitcoin Core"
4git push origin build_msvc -f

Visual Studio build configuration for Bitcoin Core ef7beaea6a

sipsorcery force-pushed on Aug 10, 2018

sipsorcery commented at 7:20 am on August 10, 2018: member

@MarcoFalke sure, done.

MarcoFalke commented at 2:00 pm on August 13, 2018: member

ACK ef7beaea6abcaab389ccb486a8f25bc4512b99ed

MarcoFalke merged this on Aug 13, 2018

MarcoFalke closed this on Aug 13, 2018

MarcoFalke referenced this in commit afa9600020 on Aug 13, 2018

ysangkok commented at 3:27 pm on August 20, 2018: none

The commit description is wrong, the secp256k1 PR has been merged into vcpkg in Oct 2017: https://github.com/Microsoft/vcpkg/pull/2005

sipsorcery commented at 5:01 pm on August 20, 2018: member

@ysangkok not sure which commit message/comment you are referring to but yes I did a PR for libsecp256k1 and vcpkg at around the same time I did this PR. The upshot of it is that all the dependencies for building bitcoin core, sans the Qt projects, can be obtained with vcpkg.

ysangkok commented at 5:07 pm on August 20, 2018: none

I was referring to https://github.com/bitcoin/bitcoin/commit/afa960002086419feeaf3e50a7003855d39c8111 . The issue seems to be that Git doesn’t know about markdown so I couldn’t see the strike-through…

MarcoFalke referenced this in commit 8da1aa471e on Apr 29, 2019

sipsorcery deleted the branch on Jun 19, 2019

ghost commented at 1:26 am on September 29, 2020: none

Build the Visual Studio solution which, if successful, will result in all but the Qt dependent libraries/programs being built.

Is it possible to build bitcoin core with Visual Studio 2019 including bitcoin-qt?

https://bitcoin.stackexchange.com/questions/99241/anyone-tried-building-bitcoin-core-with-visual-studio-2019

I even tried vcpkg install qt5 and vcpkg install qt5-base:x64-windows but didn’t help

PastaPastaPasta referenced this in commit ffb6b7c210 on May 26, 2021

PastaPastaPasta referenced this in commit 0687c9a9f5 on Jun 27, 2021

PastaPastaPasta referenced this in commit af67ca3268 on Jun 28, 2021

PastaPastaPasta referenced this in commit f4d7177988 on Jun 29, 2021

PastaPastaPasta referenced this in commit 2618b52d3c on Jun 29, 2021

PastaPastaPasta referenced this in commit fd2b028aba on Jun 29, 2021

PastaPastaPasta referenced this in commit 07e1a914af on Jun 29, 2021

PastaPastaPasta referenced this in commit a9bf129d18 on Jun 29, 2021

linuxsh2 referenced this in commit 78e9c711a6 on Jul 29, 2021

linuxsh2 referenced this in commit 638ecb1b0e on Sep 16, 2021

Munkybooty referenced this in commit a6b968a158 on Oct 7, 2021

Munkybooty referenced this in commit bf5ed75d6c on Oct 14, 2021

Munkybooty referenced this in commit 8f122fe892 on Feb 1, 2022

DrahtBot locked this on Feb 15, 2022

Visual Studio build configuration for Bitcoin Core #11526