Visual Studio 2013 build configuration

Components are organized as follows:

builds/

Parent directory for builds by system. The organization is patterned after ZeroMQ.

builds/msvc/

Directory for MS Visual C/C++ builds. Contains resources that are shared across solutions, such as DLL version resource files.

builds/msvc/build/

Build scripts for command line builds execution. buildbase.bat is a reusable build template. buildall.bat is a simple invocation wrapper for the Visual Studio solutions of interest.

builds/msvc/properties/

Properties files that define typical build configurations. These are referenced by project files as follows:

  <ImportGroup Label="PropertySheets">
    <Import Project="$(ProjectDir)..\..\properties\$(Configuration).props" />
    <Import Project="$(ProjectDir)..\..\properties\Output.props" />
    <Import Project="$(ProjectDir)$(ProjectName).props" />
  </ImportGroup>

Typically .vcxproj files are filled with large numbers of redundant and often inconsistent configurations. The proper use of .props files in this manner allows this confusion to be entirely eliminated. These files, along with buildbase.bat are maintained in a dedicated repository and utilized in a number of other projects.

builds/msvc/vs2013/

Solution directory containing the Visual Studio 2013 solution file (.sln) and subdirectories for each project. Sibling directories for VS2012 and VS2010 can be generated from the VS2013 files.

A solution is a set of projects. Projects correspond to build instructions for a given binary output, typically a library (.dll and/or .lib) or executable (.exe).

The directory contains import files that expose options and related user interface to dependent external projects, specifically secp256k1.import.props and secp256k1.import.xml. The bench and test projects also reference these imports as they each depend on the main library.

The solution directory contains the following sub directories for secpk256k1 projects:

builds/msvc/vs2013/secp256k1

builds/msvc/vs2013/secp256k1_bench

builds/msvc/vs2013/secp256k1_tests

Each of these contain the following files:

• .vcxproj contains the source file listing and standard build configurations
• .filters organizes source files in the IDE
• .config references the NuGet packages on which the project depends (GMP/MPIR and OpenSSL)
• .props contains all of the custom configuration for the build
• .xml instructs the IDE to create presentation for options exposed by the project

Note that the build will not complete until compilation issues in the source files are resolved. The build system is being pulled first in order to (1) facilitate that process, and (2) start with a 'test' that defines success by failing until other work is complete.

Without a way to keep enforce consistency with the actual code (either through a Travis test, or means to automatically generate the VS build files), I don't think this is particulatly useful, especially now with a lot of the code still being actively refactored.

Travis support would be nice. I can maintain this on my fork and issue pull requests for the source breaks.

Pull requests for source problems in VS are very welcome.

Great. We are using the lib in libbitcoin and supporting gcc/linux, clang/osx and vc/vs/windows and the more I can push back here the easier it is. Secp256k1 was a key piece in allowing us to eliminate the openssl dependency.

@evoskuil you are using this in production releases of consensus critical code? :(

At the recommendation of Peter Todd to move away from OpenSSL.

Libbitcoin is a toolkit, it's up to the user to determine whether the implementation is appropriate for a production release - whatever they deem that to be.

@petertodd I think it is unwise to use this code for consensus code at this time.

@genjix Sorry if you misunderstood me. I meant to say that Bitcoin Core was looking to replace OpenSSL with libsecp256k1, however libbitcoin shouldn't actually make that switch until Bitcoin Core does as well.