Day 4 : 11 June 2022 : Building on Windows using the Visual Studio IDE

My 100 Daze of Code

https://github.com/davidjwalling/100-days-of-code

Day 4 : 11 June 2022 : Building on Windows using the Visual Studio IDE

Today we'll add Windows support by creating a Visual Studio 2019 solution, a properties file, project files for our library and executable and demonstrate building Ava using the Visual Studio IDE.

Set Up the Solution

Clone the Existing Repository

On Windows, I keep all my repositories in a C:\repos folder. So here, I'll clone the 100-days-of-code repository while in C:\repos.

Create the Solution File

I'm running Visual Studio 2019 Community Edition on Windows 10. Launch Visual Studio and on the starting dialog select "Create a new project". Select "Blank Solution" and click Next. Name your solution (I'm using "ava") and click Create. Close the solution.

Visual Studio likes to create a folder and place the solution file (.sln) in it. I prefer to locate the solution, properties and project files all together instead. So, I close the solution, locate where the .sln was created and move it to the local repository folder. 


Open the existing solution file in Visual Studio. Visual Studio will detect the presence of the .git folder and display the current repository and branch.


Create the Project Files

Next, we'll create project (.vcxproj) files for the library and executable and add our source files to the respective projects. Here also, Visual Studio will want to create the projects in their own folders. If it does so, close and remove the projects, locate and move the .vcxproj and related files into the base repository folder and then add the existing projects back to the solution.

Your file organization should now look like this:


Now, if you are part of a team whose members use Visual Studio, you might want to consider adding the "*.vcxproj*" files to your ".gitignore" file if your local VS settings may differ.

Add Source and Header Files to the Projects

Add the source (.cpp) files and the header (.h) file to the appropriate project folders in Visual Studio. Also, add "libava" as a dependency in the "ava" project as shown.


Create the Properties File

In Visual Studio, we can define a single Properties file and apply all of its settings to each configuration and platform combination. Then the project files will inherit these base properties and can extend or override them.

Use the "View" --> "Other Windows" --> "Property Manager" menu item to open the Property Manager dialog. Click the "Add New Project Property Sheet" icon to open the Property Sheet dialog. Name the property sheet. Here, we'll use "ava.props" and click "Add".

Right-click on each project and add the new property sheet to it. Confirm that the property sheet is now listed for each configuration.


Setting Properties in the Properties File

The Visual Studio project and properties settings are largely up to the individual developer. The settings shown here are my personal preferences.

In the properties file ava.props, I set the output and intermediate output folders by platform and configuration and isolate intermediate output. This keeps our CMake output in "build" separate and organizes Visual Studio IDE compilation output as follows. 

Win32 ---+--- Debug -----+--- ava
         |               +--- libava
         +--- Release ---+--- ava
                         +--- libava
x64 -----+--- Debug -----+--- ava
         |               +--- libava
         +--- Release ---+--- ava
                         +--- libava


I set the Debug Information Format to "Program Database (/ZI)" and set the Warning Level to the highest level, "Level4 (/W4)".


These are the preprocessor directives I usually set. Some of these are helpful when using legacy sockets API functions.


I set the calling convention on Windows to "__stdcall (/Gz)" to reduce stack usage. But, this is only relevant to 32-bit compilations, which are increasingly rare for Windows apps.


I disable incremental linking add a reference to help the executable locate the dependent library.


Setting the Library Project Settings

Both the library (libava) and executable (ava) will inherit the settings from the Properties file described above. But each also needs some specific settings at the project level. Here we set the settings for the library in libava.vcxproj. Remember to set these for each platform and configuration combination that you plan to create.

For the library, set the Configuration Type to "Dynamic Library (.dll)". The Windows SDK Version and Platform Toolset are left at the default values.


Since the program will be reading and writing 8-bit ASCII bytes on the network, I avoid MBCS to Unicode string translation by just using Multi-Byte Character Set. I usually disable Whole Program Optimization.


Add the "_WINDLL" preprocessor definition to all configurations of the library. 


Setting the Executable Project Settings

For the executable, the Configuration Type is "Application (.exe)". 


As with the library, here also I use Multi-Byte Character Set and disable Whole Program Optimization.


For the executable, we need to specify our library as a Linker Input.


Debug with the Visual Studio IDE

Now compile and debug using the Visual Studio IDE.








Comments

Post a Comment

Popular posts from this blog

Day 12 : 19 June 2022 : Adding Windows Service Logic

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #12 : Adding Windows Service Logic Today, we'll add some Win32 API logic in Ava to install, uninstall and run as a service on Windows. We'll add logic in Driver::Service that check if the program was started with the "service" argument as the first program argument. If so, the Service Control Manager will be invoked to start the program as a service. We'll also check for "install" and "uninstall" program arguments and handle these with logic that installs and uninstalls the program, respectively. In a later post, we'll do the equivalent on Linux and macOS and show how to enable Ava to run as a daemon configured in sysctl. Nowadays there are shortcut methods to install and run an executable as a service on Windows. But I prefer to illustrate the APIs that make this work. Some Code Refactoring Up to now we've been using a pointer-to-implementation (pimpl) method for exp...
Read more

Day 5 : 12 June 2022 : CMake on Windows

Image
 My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code Day 5 : 12 June 2022 : CMake on Windows So far, we've seen using CMake on Linux and MacOS. Also, we've looked at native compilation on Windows using Visual Studio (VS). Today, we'll look at using CMake on Windows. I decided to devote an entire day (hour) to this because there are several ways to invoke CMake on Windows, using different "Generators". A generator will write the inputs to the native build tools. But Wait, There's More ... Before heading to CMake, I wanted to first point out that VS' native tools can build just fine without using CMake, of course. To build using "msbuild," open an x64 Native Tools Command Prompt for Visual Studio - this is provided when VS is installed. Invoke msbuild and pass the solution name and the desired platform and configuration. msbuild ava.sln /p:Platform=x64 /p:Configuration=Debug Repeat for Debug and Release configurations for Win32 an...
Read more

Day 11: 18 June 2022 : Handling Program Arguments

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #11 : Handling Program Arguments Up to now we've been carrying around Ava's program argument count (argc) and value array (argv) into a Configure method. Now it's time to start doing something with those values. We'll define four program settings that can be set by passing program arguments: the logging level, path, prefix and suffix, and show examples of using them. Logging Parameter Storage The singleton theLog is instantiated inside the Ava library (libava). Default values for several logging parameters are set by the Log::Init method, which is called both by the Log class constructor and the destructor, by way of the Reset method, so that runtime values are not left in deallocated storage on operating systems that do not automatically clear memory upon deallocation. Logging Parameter Symbols We use namespaces and enums to define symbolic names for the logging parameters so that we have a single lo...
Read more