New Software Development Process, Part 4 - Installing wxWidgets, the Cross-Platform Application Frameworks

Instead of installing the current stable release of wxWidgets, version 2.8.10, I took a risk and installed the latest development snapshot release, version 2.9.0.

In version 2.9.0, the distinction between ANSI and Unicode builds were removed. Our legacy applications were written with strings using the ANSI/ASCII character set. This new feature, in version 2.9.0, would help us quickly transition our legacy application to Unicode.

Also, version 2.9.0 supports both the 32-bit and 32-bit/64-bit version of Cocoa in Mac OS X.

These two new feature in version 2.9.0 are so critical for us that I was willing to take the risk and not wait (until next year) for the next stable version, with these features, (version 3.0.0) to be released.

While the wxWidgets 2.9.0 build for Visual Studio/Visual C++ was successful, I was not able to build wxWidgets 2.9.0 for GCC MinGW. I was not able to get pass the configure step. In wxWidgets 2.9.0, they eliminated the "contrib" subdirectory but the script for building the WxWidgets library did not reflect the change.

I resorted to installing the current stable release, wxWidgets 2.8.10. These steps are the ones that I took to installed it.


I created the sub-folder
C:\SWDevTools\wxWidgets

Then, I created the sub-folder
C:\SWDevTools\wxWidgets\download

Using my web browser (Mozilla Firefox), I went to:

http://www.wxwidgets.org/downloads/

and clicked on the link to the "Current Stable Release: 2.8.10".

Using the link to "wxMSW - installer for Windows, with manual (other formats: zip)", I downloaded the file "wxMSW-2.8.10-Setup.exe" to C:\SWDevTools\wxWidgets\download


I scanned the file "wxMSW-2.8.10-Setup.exe" for viruses and then executed it.

Specify that wxWidgits be installed in

C:\SWDevTools\wxWidgets

After executing wxMSW-2.8.10-Setup.exe, I set the environment variable

WXWIN

to

C:\SWDevTools\wxWidgets


To switch on wxGLCanvas support on Windows, I edited the setup.h files and set wxUSE_GLCANVAS to 1, before building wxWidgets.

I edited the following files:
C:\SWDevTools\wxWidgets\setup.h.in
C:\SWDevTools\wxWidgets\include\wx\setup_inc.h
C:\SWDevTools\wxWidgets\include\wx\msw\setup.h
C:\SWDevTools\wxWidgets\include\wx\msw\setup0.h
C:\SWDevTools\wxWidgets\include\wx\msw\wince\setup.h
C:\SWDevTools\wxWidgets\include\wx\msw\setup_microwin.h

Note: Make sure to look for all instances of
"#define wxUSE_GLCANVAS"
in each file.

To build wxWidgets for Visual Studio 2005, I opened the Visual Studio/Visual C++ 6.0 workspace file wx.dsw using Visual Studio 2005 and allowed it to convert the project files from Visual Studio/Visual C++ 6.0 format to the Visual Studio/Visual C++ 2005 format.

I selected the "Build" menu item from the Visual Studio menu bar to activate its drop down menu.

From the drop down menu, I selected the "Batch Build..." menu item.

When the "Batch Build" dialog appeared, I selected all the projects that are not DLL projects and are not "Universal" projects.

Then, I clicked the "Build" button.

Since this process will take a long time, I took a lunch break while Visual Studio is building wxWidgets.

NOTE: In the past, I've deployed applications with DLLs and maintaining client's software by updating DLLs. However, more often than not, I've ended up updating almost all the files. Also, these days, everyone has ridiculously huge amount of mass storage space so the amount of disk space saved by the use of DLLs is not really an issue. My cost benefit analysis of the use of DLLs led me to believe that they are more trouble than they are worth. If you disagree, select the DLL projects for the batch build.

NOTE: The "Universal" projects are for when the application GUI will look identical on all platforms. i.e., the GUI does not conform the default style of the operating system GUI "look".

NOTE: Theoretically, I do not need to generate the "release" build of wxWidgets for Visual Studio 2005 since we will be using Visual Studio 2005 only for debugging. We will be using the GCC tools for producing our final products across all the target platforms. However, I've been in software development long enough to know that there will be a time in which we need to deploy a product before we can figure out why the source code can be compiled by Visual Studio 2005 and not be compiled by the GCC compiler. In such a case, we'll deploy the Windows version of the application generated by Visual Studio 2005 and deploy the versions for other platforms when we figure out how to compile the source code with the GCC compiler. So, I generated the "release" builds of wxWidgets for Visual Studio 2005.



To build wxWidgets for GCC MinGW, I executed MSYS from the MS Windows "Start" menu.

Start -> MinGW -> MSYS -> MSYS

When MSys' text terminal window opened, I performed the builds using line commands.


For creating the release/ansi build, I used the following command.

cd /C/SWDevTools/wxWidgets/build

../configure --build=x86-winnt-mingw32 --with-msw --enable-release --enable-ansi --disable-precomp-headers --disable-shared --disable-monolithic -–disable-threads --disable-sockets --with-openGl


cd /C/SWDevTools/wxWidgets/build/msw

mingw32-make -f makefile.gcc MONOLITHIC=0 SHARED=0 UNICODE=0 USE_OPENGL=1 BUILD=release


Since "configure" and "make" take a very long time; I found other things to do while each ran.


NOTE: I built wxWidgets for GCC MinGW without the threads feature; it relies on mingwm10.dll and I don't want to add unnecessary burden to the deployment of our applications. We will employ threading using macros and inline functions defined in the set of c++ header (.h) files that compose the abstraction layer for making operating system calls.

NOTE: I built wxWidgets for GCC MinGW without the sockets feature; the wxWidgets classes for socket communication is too restrictive for the type of network communication uses in our applications. We will perform socket functions using macros and inline functions defined in the set of c++ header (.h) files that compose the abstraction layer for making operating system calls.



For creating the release/unicode build, I used the following command.

cd /C/SWDevTools/wxWidgets/build

../configure --build=x86-winnt-mingw32 --with-msw --enable-release --enable-unicode --disable-precomp-headers --disable-shared --disable-monolithic -–disable-threads --disable-sockets --with-openGl


cd /C/SWDevTools/wxWidgets/build/msw

mingw32-make -f makefile.gcc MONOLITHIC=0 SHARED=0 UNICODE=1 USE_OPENGL=1 BUILD=release

Since "configure" and "make" take a very long time; I found other things to do while each ran.



For creating the debug/ansi build, I used the following command.

cd /C/SWDevTools/wxWidgets/build

../configure --build=x86-winnt-mingw32 --with-msw --enable-debug --enable-ansi --disable-precomp-headers --disable-shared --disable-monolithic -–disable-threads --disable-sockets --with-openGl


cd /C/SWDevTools/wxWidgets/build/msw

mingw32-make -f makefile.gcc MONOLITHIC=0 SHARED=0 UNICODE=0 USE_OPENGL=1 BUILD=debug


Since "configure" and "make" take a very long time; I found other things to do while each ran.



For creating the debug/unicode build, I used the following command.

cd /C/SWDevTools/wxWidgets/build

../configure --build=x86-winnt-mingw32 --with-msw --enable-debug --enable-unicode --disable-precomp-headers --disable-shared --disable-monolithic -–disable-threads --disable-sockets --with-openGl


cd /C/SWDevTools/wxWidgets/build/msw

mingw32-make -f makefile.gcc MONOLITHIC=0 SHARED=0 UNICODE=1 USE_OPENGL=1 BUILD=debug


Since "configure" and "make" take a very long time; I found other things to do while each ran.



NOTE: Theoretically, I do not need to generate the "debug" build of wxWidgets for GCC MinGW since we will be using GCC MinGW only for producing our final products. We will be using the Visual Studio 2005 for debugging. However, I've been in software development long enough to know that there will be a time in which we need to figure out why we are able to compile the source code using Visual Studio 2005 but not with GCC MinGW or why an executable generated by GCC MinGW does not perform the same as the executable generated by Visual Studio 2005 from the identical source code. So, I generated the "debug" builds of wxWidgets for GCC MinGW.