Day 11: 18 June 2022 : Handling Program Arguments

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 location where these values are defined instead of running constant literals throughout the code.

Applying Program Arguments

In IDriver::Driver::Configure, we'll set initial values for variable parameters that cannot be constant. Then we'll hierarchically apply settings from several sources: on Windows, from the Registry, and then, on all platforms, from the Environment, a local configuration file and, finally, program arguments. We do this to allow settings to be scoped at the system, user, folder and instance levels.

For Today, we'll just introduce the lowest level of configuration - handling command-line arguments. After default value are set, we call GetArgVars. This method will walk the program arguments and apply the values provided for "keyword" parameters. It also checks the first argument, which might be the "positional" argument with a value of "service" if the program is intended to be run as a Windows service or a Linux daemon.


We use the "err" logging macro for the first time, to produce an error message if the log level name provided as a program argument is not recognized.

Other Changes

Two other changes of note Today: First, we've removed the "ava" namespace, as that was causing more trouble than it was worth. Also, we're no longer including "api.h" from "driver.h" since that exposes a lot of implementation detail that the application layer does need. In fact the only thing we need to do in driver.h is define "EXPORT" and "__cdecl" for the purposes of importing or exporting public symbols.

Running Ava with Program Arguments

To debug in Visual Studio on Windows, we can set the Command Arguments in the project settings for the executable. Note that when debugging, the Current Working Directory (cwd) is the folder where the solution file (ava.sln) is located.

The output shows the settings being reported.

Here we'll run ava on the command-line and pass program arguments for the log level, path, prefix and suffix. Then, we'll observe the location and naming of the log file generated. Note that the path specified in the path/directory parameter (-d) must exist. Otherwise, the initial logs will remain the file "prelog".





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