1. Presentation Name / 1 www.ezesoft.com Visual C++ Builds and External Dependencies NAME

2. Presentation Name / 2 About Us  Leader in building and servicing financial technology since 1985; providing “Cloud” solutions since 1996  2,000+ institutions including hedge funds and traditional asset managers  Software and service supporting the full investment lifecycle  Features include trade order and execution management; compliance; portfolio accounting; and real-time market data as an internet service  More than 25 years of working with Microsoft Visual C++  Current software stack is mostly C++ native code on windows

3. Presentation Name / 3 An Evolution of Builds

4. Presentation Name / 4

5. Presentation Name / 5

6. Presentation Name / 6

7. Presentation Name / 7

8. Presentation Name / 8

9. Presentation Name / 9

10. Presentation Name / 10

11. Presentation Name / 11 End of the line  Version control is tasked with storing all binaries and third party libraries, and becomes unmanageable  Build are difficult to reproduce  Build process becomes tightly coupled to the version control system

12. Presentation Name / 12 Why are C++ builds so hard?  Libraries come simply as header files and some kind of binary lib, with no structured manifest.  Differences between versions of the compiler and standard library will break binary compatibility.  C++ projects are often targeting multiple platforms (32bit, 64bit) or operating systems (Windows, Linux).

13. Presentation Name / 13 The pre-processor and parser  The C++ parser is single pass, so all symbols must be declared before they are used, and order matters.  The compiler has no knowledge of libraries, and instead depends on the preprocessor to unroll all includes and present it with a single text stream. Unlike modern languages that can provide the compiler with a structured manifest.  With its use of #ifdefs, #defines, #includes, etc… the preprocessor can be very complex.  The behavior of the preprocessor and compiler is very dependent on the environment in which it runs, including system configuration, compiler version, “system” header files, and environment variables.

14. Presentation Name / 14 The linker  Dependent on environment variables and system libraries  Object files carry no information about their contents beyond the names of the symbols. The linker cannot verify the correctness of the link beyond matching names.  Every member of an object’s dependency tree must be present and specified for a link to succeed, however there is no way to discover this info without knowing this info ahead of time.

15. Presentation Name / 15 What’s Next? Dependencies!!!

16. Presentation Name / 16 What are dependencies  Everything you need to build your application  Code  Headers  Libraries  Pre-Preprocessors  Compilers  Linkers  Tools

17. Presentation Name / 17 How do we manage dependencies?  There is a whole world of package managers out there for other systems….  What about Visual C++?

18. Presentation Name / 18 What is NuGet  NuGet is a package manager originally designed to work with Visual Studio and the.net platform.  All NuGet packages are identified by their package ID and their version.  Packages.config lists all the packages for a project.  Packages can come from anywhere  NuGet Packages can have dependencies of their own.  This is the structured metadata we need!

19. Presentation Name / 19 NuGet for C++  As of version 2.5, NuGet added support for C++ projects.  Originally, NuGet packages just contained dependency files and required the IDE to figure out the correct behavior based on context and file types.  To support C++, NuGet packages have to be able to modify the msbuild scripts for the project.  When a C++ NuGet package is added to a project, any msbuild properties or targets files are imported into the project’s msbuild script.

20. Presentation Name / 20

21. Presentation Name / 21 DEMO

22. Presentation Name / 22 What’s Next?

23. Presentation Name / 23 Ultimate Reproducibility and Containment  Storing the entire build server environment as metadata.  Compilers and other tools could be distributed as NuGet packages or possibly as docker containers referenced by NuGet packages.  Microsoft seems to be embracing the model, and we might soon see the Microsoft compilers shipped as packages.  Only need your source repository and msbuild to build your application on any machine.

24. Presentation Name / 24 Q&A