MSVC build integratin #4858

Moved out of pull thread: @ENikS fwiw, I think a much more realistic next step would be to get a mingw environment up and running under Windows. That I could help with much more, as I'd like to see it happen. We already have a system for building dependencies on/for various platforms (it already builds for windows), it would need to be adapted for use on Windows. You could then use them to build bitcoin with mingw, or coerce it into building with msvc @theuni We could do that but to build all the dependencies and BitcoinD you don't need mingw. I do have a bitcoin-dev-msvc project which builds them all and runs on MS natively.

QT was outside of my area of interest so far. It could be added, but I do not see it as a problem either, it was done once by Claire DuSoleil for version 0.8.6.

We could do that but to build all the dependencies and BitcoinD you don't need mingw

Of course you don't need mingw for that. Because of ABI issues you must build the dependencies with the same compiler that you use for bitcoin itself.

His idea is to make it easier to build in mingw in windows (i.e. just make -C depends && ./autogen.sh && ./configure like in other OSes). But that's completely parallel to the topic of building in MSVC. Different people have different choices in compiler, and it's no problem to accommodate multiple choices as long as someone actively maintains them.

Qt in MSVC is a study in itself, BTW. At least back in ~2011 there was official support for Qt in the paid versions of MSVC using a plugin, but with the free version you needed custom hooks and hacks to handle MOC, UI generation but it is possible (although this is a problem with the MSVC build system, not the compiler as such).

And what is the issue with mingw? I thought it should be exactly the same on each and every platform.

As for running make and configure scripts it should be modified for each platform. Naked .sh will not satisfy all the requirements. Perhaps more flexible solution such as boost uses (jam/b2) should be used for cross platform builds. That I know for a fact will use same configuration on each and every platform. I've looked into their b2/bjam code (trying to integrate with VS) and am very impressed with it.

As for running make and configure scripts it should be modified for each platform.

That's true for every build system, in practice. Nothing just works instantly on any new platform. automake/autoconf in itself is platform independent as well, but when building native software there are always platform-dependent weirdnesses that have to be taken into account.

I don't feel like arguing the pros and cons of build systems here. We only recently switched from loose makefiles to autoconf/automake, which is only now starting to stabilize and "just work". Switching to something else again means going through another phase of build system frustration.

(if you want my personal opinion about build systems: I prefer cmake, which can generate MSVC solution files.. but as said that doesn't matter here)

@laanwj Don't get me wrong, I am not advocating any changes, I just merely trying to understand what is the issue.

(if you want my personal opinion about build systems: I prefer cmake, which can generate MSVC solution files.. but as said that doesn't matter here) @laanwj After trying to set it up on Win 7 VM and reading all I could find about autotools I would agree and ask why such limiting choice was made? It might not matter but I am kind of curious.

Playing with MinGW on Windows and trying to build project I came across roadblock: some unit tests require header files to be generated based on json and raw files. The process is based on hexdump utility which is not available on Windows OS.

Question: Is it really necessary to regenerate on each and every build and even if so can results still be added to source control so less fortunate OSs could skip this step?

@ENikS Because there are lots of OSs out there and Windows is the least used for Bitcoin development. If you're going to continue down this path, you really must recognize that the Windows dev environment you're used to is not the de-facto for this type of project. You're going to have to get out of your comfort zone.

Hexdump can be built by depends or a suitable replacement can be used. That's what autotools brings to the table.

@theuni It could be downloaded from Cygwin utils as well by why? If you are so inclined to keep dev process as static as possible why not include generated files into source control so there could be middle ground for all platforms? Since Unix is not the only build platform anymore why not provide more flexible solution?

Just to give you an example:

I am trying to add all unit tests to the project but they include these tricky header. I can't just say "HEXDUMP xyz file" in command prompt, I can not do in in simple Perl either. So for me to just generate these files I have to go through entire build process with Mingw on Windows. I already spent whole weekend trying to generate these few files and for what?!

Don't get me wrong but it looks like you deliberately trying to make this process as hard as possible for other people working on other platforms. I do understand that it is probably my frustration talking and reality is different but it definitely looks like it for me at the moment.

No, I am attempting to make the process as portable as possible, which means that all platforms must converge somewhere. You have gotten as far as hexdump and have already decided that checking in generated files is the proper solution. This means that test data can't be reviewed and the authors must be trusted. What happens when you get to protoc and qt. Then what? Check those in too?

We're not going to reinvent our build process for this. If you would like help with the porting process, I've offered that help. But trying to shoe-horn our source tree into msvc is an exercise in futility. For both of us. If you continue to discuss this as though our reasoning has been arbitrary and can be tossed aside, you will continue to be met with opposition.

A batch script should be written that builds the necessary tools with mingw, builds the dependencies with them, and add them to a path relative to the solution file. That file can then enumerate the to-be-processed files via BuildDependsOn or so, complete with custom commands.

A batch script should be written that builds the necessary tools with mingw, builds the dependencies with them, and add them to a path relative to the solution file. That file can then enumerate the to-be-processed files via BuildDependsOn or so, complete with custom commands. @theuni This is exactly where I got stuck. I could not get my hands on a copy of these to see what needs to be done to generate headers. Can you point me to where I can download all the generated headers or perhaps you could just email them to me?

As for your offer of help with MinGW setup I would gladly accept it. I am in a process of setting WIN7 VM with MinGW but got stuck in a middle of executing of Configure script. Although all dependencies are built and installed the script couldn't find any of them. I am using this one as a guide but it fails if executed in described order: https://bitcointalk.org/index.php?topic=149479.0

Doesn't look like anyone cares

@ENikS That's not the problem, just that github comments are not the right place to discuss this since the work will be quite involved. A discussion on IRC would make this much easier to get it started. If you're interested, please ping me in #bitcoin-dev on freenode. I'm cfields or coryfields there.