Building Alternative Executable in RiverWare Source Tree (Revised).
 Phil Weinstein, CADSWES, Edit: 6-22-2015.

Document Home:

Document Status:

(1) Overview

Primarily as a proof-of-concept for a design provision of a new RiverWare Scenario Explorer application, changes to the Windows Visual Studio 2010 build were devised to support the creation of distinct executables (i.e. other than just riverware.exe) in the RiverWare source tree.

The two main technical requirements for the build process are:

  1. Distinct names for each application's generated executable file.
  2. Definition of a variable (in C++ code) indicating the built application.

As a demonstration, a second application is built from the RiverWare source tree which consists of only the RiverWare Unit Converter. Closing this dialog exits the application:

A prior version of this document described a different approach to making use of Qt's qmake provisions to provide symbols to C++ code which indicated the built application. This fundamentally resulted in new Visual Studio "vcxproj" files being generated each time the build was switched between applications. That was undesirable.

At the time of this writing, this alternative executable capability had already been extended to a third application: a very limited prototype of the new "RiverWare Scenario Explorer," primarily demonstrating a "workspace thumbnail" panel. The instructions and descriptions below are for a the building 64-bit versions of all three of these executables:

  1. riverware.exe
  2. UnitConverter.exe
  3. ScenarioExplorer.exe

The following sections describe the various source and build components support the building of these three applications from a single source tree, with a single Visual Studio 2010 solution (.sln) file.

(2) New module: Sim/RwAppContext.hpp

This contains the following definitions:

     
typedef enum { 
  RwAppContext_ClassicRiverWare = 0, 
  RwAppContext_UnitConverter, 
  RwAppContext_ScenarioExplorer  
} RwAppContextType;    
 
extern const RwAppContextType RwAppContext;

(3) EngrObjs/riverware.cpp moved to EngrObjs/mainImp.cpp.

This has the "main" function, which has been renamed to "mainImp".

(4) Addition of three new modules having a "main" function:

  1. EngrObjs/riverwareApp.cpp
  2. EngrObjs/UnitConverterApp.cpp
  3. EngrObjs/ScenarioExplorerApp.cpp

Here is the significant content of the third one:

     
#include "RwAppContext.hpp"  // [Sim]

// global variable
const RwAppContextType RwAppContext = RwAppContext_ScenarioExplorer;

extern int mainImp (int argc, char** argv);  // [mainImp.cpp]

int main (int argc, char** argv)
{
   int retCode = mainImp (argc, argv);
   return retCode;
}

(5) EngrObjs/riverware.pro moved to EngrObjs/rwApplication.pri.

The only change to the content of this ~220 line file is that the following lines are commented out:

     
  # These symbols have been moved to a higher level .pro file
  #-- HEADERS = version.hpp
  #-- SOURCES = riverware.cpp version.cpp

(6) Created three new "top level" .pro files, for the executables

  1. EngrObjs/riverware.pro
  2. EngrObjs/UnitConverter.pro
  3. EngrObjs/ScenarioExplorer.pro

Here is the significant content of the latter:

     
HEADERS = version.hpp
SOURCES = ScenarioExplorerApp.cpp version.cpp mainImp.cpp

include(rwApplication.pri)

(7) New code in function rwGUIExecute() in GUI/rwGUIInit.cpp:

     
// Unconditionally instantiate the RiverWare Workspace GUI
Workspace* workspace = Workspace::instance();
 
 switch (RwAppContext) // global constant
{
   case RwAppContext_ClassicRiverWare:
       workspace->show();
       break;
 
   case RwAppContext_UnitConverter:
       UnitConvertDlg::showDlg();
       break;
 
   case RwAppContext_ScenarioExplorer:
       ScenarioExplorerDlg::showDlg();
       break;
 
   default:
       rwAssert (("Unsupported RwAppContext", 0));
}

(8) Additions to Makefiles/qmake.pl:

     
chdir 'EngrObjs';
make ('riverware');
make ('UnitConverter');      # ADDED
make ('ScenarioExplorer');   # ADDED
chdir '..';

(9) Visual Studio 2010 Configuration

The following instructions are not comprehensive. They focus on the differences of the Visual Studio 2010 configuration from the prior variation.

Two areas need to be configured for switching the build between the different supported applications (executables):

  1. The solution's selected "StartUp project".
  2. The solution's (project-) Configuration Manager.

(9a) Visual Studio 2010 Startup Project

The project for the desired application needs to be set as the solution's "StartUp Project". This is done using a context menu operation of the project item within the Visual Studio Solution Explorer panel. Note that Visual Studio indicates the currently selected StartUp Project with bold text.

(9b) Visual Studio 2010 Configuration Manager

Only one of the three "executable" Visual Studio projects should be enabled for the Build -- the one corresponding to the currently set StartUp Project. This is set within the Configuration Manager, accessible from the indicated combo box.

     

Note: The "Win32 / x64" project platform combo boxes in Visual Studio 2010 have some quirks. For one thing, the visible state (e.g. "x64") does not necessarily actually exist for the particular project. You need to open up each cell's combo box to confirm that it does exist, and is selected.

Another anomaly is that the projects' Build enabled states (checkboxes) are specific to the Debug or Release selection. They must be correctly set for each of those two solution configurations.

Once a build is complete, building either of the other two applications (i.e. after making both types of changes described above), is very quick.

--- (end) ---