Project – Enable C++11 Compiling

By default, GCC C++ compiles for the corrected C++98 standard (C++03) with GNU extensions (there is no option for compiling for the uncorrected original C++98 standard).  There are two options for compiling C++11, one for the standard and one with GNU extensions.  The option for the standard C++11 will be used and was added to the CMake build file.

Though not necessary, I decided that it was a reasonable idea to validate that C++11 compiling was enabled and that C++11 was supported while generating the make file.  This meant adding a try_compile command to the CMake build file for a simple C++11 program.  If compiling of the simple program fails, an error is reported and CMake aborts.

The initial simple C++11 program tests two C++11 features.  As more C++11 features are used in the project, this simple program will be expanded to test those features also.  The two initial features tested are the new universal initializer syntax and the new null pointer.  Click Continue... for details of these two features.

I discovered something about CMake syntax, namely else and endif statements no longer require repeating the expression in the if statement (as of CMake 2.6.0).  The expression may now be left empty.  Repeating the expression can sometimes be misleading, for example:

if (NOT ${SOMETHING})
    ... <not something processing here> ...
else  (NOT ${SOMETHING})
    ... <something procession here> ...
endif (NOT ${SOMETHING})

Which makes it seem like the else part is for handling the "not something" condition.  Leaving the expression blank, as in else() and endif(), is much less confusing.  The rest of the if-else-endif statements in the CMake file will be updated to this style at some point.  (This syntax was already used for handling issues with Windows.)

There was also a statement in the CMake build file that obtained the GCC version for checking, but statements that were checking the version have been since removed, so this statement was also removed.  Work is now taking place on a new cpp11 branch.

[branch cpp11 commit 18ed38e9af]

Building and Running on Windows 8.1 – Command Line

The application can also be built using the command line, either from the Windows Command Prompt or from the BASH shell that comes with Git for Windows named Git Bash in the menu or start screen.  However, the procedure is slightly different between the two.  The procedures below include cloning the IBCP Git repository.  Here are the steps for using Git Bash:

1. cd Documents
2. git clone https://github.com/thunder422/ibcp
3. cd ibcp                               (shows master is the current branch)
4. git checkout branch0.6                (now shows branch0.6 is the current branch)
5. cd ..
6. mkdir ibcp-build
7. cd ibcp-build
8. cmake -G "MSYS Makefiles" -DCMAKE_MAKE_PROGRAM=mingw32-make ../ibcp
9. mingw32-make
10. regtest                               (runs the Linux regression test script)

In step 8, the MSYS generator looks for the make command, which it will not find because it is named ming32-make with the MinGW-w64 installation.  Therefore the make program needs to be identified on the command line.

Here are the steps for using the Command Prompt:

1. cd Documents
2. git clone https://github.com/thunder422/ibcp
3. cd ibcp
4. git checkout branch0.6
5. cd ..
6. md ibcp-build
7. cd ibcp-build
8. cmake -G "MinGW Makefiles" ../ibcp    (produces errors - see below)
9. cmake -G "MinGW Makefiles" ../ibcp
10. mingw32-make
11. regtest                               (runs Windows regression test batch file)

In steps 8 and 9, unlike the MSYS generator, the MinGW generator does look for the mingw32-make command, so the make program does not need to be specified.  In step 8 like Qt Creator, there are a bunch of errors, one screaming about sh.exe being in the path and that MinGW make won't work correctly.  This does not appear to actually affect the build however.  In step 9 again like with Qt Creator, the second time no errors are reported.

In step 11, the batch file will run all the tests and then it will compare the first set of results (parser tests).  If the tests are successful it will say OK for each file.  Answer N for comparing more files.  The next set of results will be compared.  Answer N after each comparison (otherwise it will prompt for more files to compare).

In step 8 for Git Bash and steps 8 and 9 for the Command Prompt, add -DCMAKE_BUILD_TYPE=Debug before the source directory to do a debug build.

CMake Problems Windows 8.1 – Part 3

The final build problem found with the awk script used to auto-generate the automatic enumerations header file and the codes reference text file.  The problem was that when building with Qt Creator (procedure will be provided in the next post), the build aborted with a strange error message after running this script.  It correctly built the output files, and telling it to build again allowed it to successfully complete the build.

The problem was in the part of the script that generates the codes.txt reference file that lists all the codes by code index and by code name.  This information is helpful to aid debugging, but otherwise it is not used.  To sort by code names, it pipes the code name output through the sort command.  It was desired that names like Asc_Code and Asc2_Code be sorted like this, but it was reversing these because the underscore sorts after the 2 character.

An attempt to correct this issue was made be adding the "-d" option (dictionary order) to the sort command which tells it to only recognize letters and digits ignoring underscore characters.  When building under Windows, it was calling the Windows sort command.  This sort command did not recognize this option and reported an error, which caused the build to fail.

Unfortunately, adding this option did not work as desired anyway.  The problem was that with the underscores removed, the above names become AscCode and Asc2Code and the 2 character still sorted before the C character.  This was not noticed when this option was added.  Anyway, once this option was removed, the build no longer failed on Windows.  (Curiously, the Windows sort command does sort the names as desired.)

CMake Problems Windows 8.1 – Part 2

The second problem was with the paths to the test files generated in the make file.  When CMake generates a custom command for making the test directory and copying a test file, it uses the Unix style path forward slash separator regardless of the generator being used.  While cmd.exe on Windows does support these style paths, the md and copy commands do not (in fact the forward slash indicates an option like the minus does for Linux and MSYS commands).  This obviously causes problems with the custom commands.

In CMake, the file command supports a TO_NATIVE_PATH option, but when used, this command didn't work as expected (didn't do anything).  Apparently this is a known issue and according to what I read, this is not the purpose of this command anyway.  So instead, a ConvertPath function was added to the CMake build file, which if the MinGW generator is being used, changes forward slashes to back slashes and surrounds that path with double quotes to deal with paths that may have spaces in them (which doesn't occur with the MinGW generator like with the MSYS generator).  For any other generator, the path is not changed.

Another build problem was found with the awk program required for building.  When using MSYS with MinGW, MSYS included many of the Unix utilities including the awk program.  Fortunately, Git for Windows includes many of the MSYS utilities.  However, the gawk program is included instead (stands for GNU awk).  Also included is an awk script, but this shell script is meant to be run by the sh.exe command that is part of MSYS, which just calls gawk.  When run from cmd.exe the script doesn't work.

When looking for the awk program, CMake found this awk script and so an error occurred from the make command running under cmd.exe.  To make CMake find gawk.exe instead of this script, the CMake build file was modified to look for gawk first, and if this is not found, then looks for awk.  In fact, on Linux, awk is also called gawk, but there is an awk file that soft links to it, so that either can be used.

While testing a minor mismatch was found with encoder test #2 with recreator testing.  The issue was that lines with error now store the text of the line, which is recreated.  This change was made in the last commit but the expect results were not updated.

[commit 727f7d223f]

Build Problems on Windows 8.1 – Part 1

Several problems were discovered when attempting to build and run on Windows 8.1 using Qt Creator.  The first problem that occurred was with the copying of the test files from the source directory to the build (binary) directory.  This is accomplished by creating custom commands for each test file.  These custom commands generate a mkdir -p command to make the test directory if not already there and the cp command to copy the file.  Both of these commands are available on Linux and with MSYS on Windows.

When building on the command line on Windows using MSYS to create the make file or using the CMake GUI to generator the make file, the "MSYS Makefiles" generator is used.  This creates the make file assuming that the make command will be run using a Unix shell (specifically bash or the Bourne Again SHell).

On Windows when running CMake from Qt Creator, it uses the "MinGW Makefiles" generator to generator the make file.  This generator assumes that the make command is going to be run using cmd.exe, the Windows command prompt program, which Qt Creator uses cmd.exe to run the make command.  The make command uses the program under which it is run to execute commands in the make file like for custom commands.

The CMake build file needed to be modified to detect when the MinGW generator was being used and use the appropriate make directory and copy commands for cmd.exe.  Fortunately, the CMake CMAKE_GENERATOR variable is set to the generator is being used.  So, if the generator is MinGW Makefiles, the md and copy commands are used, otherwise the mkdir -p and cp and used.

Another problem with the md command is that if the directory already exists, the command returns an error and the make command aborts.  With Linux/MSYS, the -p option solves this problem.  With cmd.exe, the md command has no similar option.  The only solution that worked was using an if not exist command (so the md command is only performed when the test directory doesn't exist):

if not exist test-directory md test-directory

When the generator is not MinGW, CMake adds double quotes about each component of an individual command in the custom command if the component has a space in it, because otherwise the shell parse a path with a space incorrectly as two arguments and not one.  For this reason, the command variable could not be set to mkdir -p because it would create the command "mkdir -p" and this is not a valid command.  Therefore, the mkdir and -p had to be put into two separate variables.  This does not occur with the MinGW generator.

Installing CMake on Windows 8.1

Building project requires the CMake utility.  CMake can be obtained from the CMake download page.  For now I suggest installing the latest 2.8 version, which is 2.8.12.2.  There is a newer version (3.0.1 at this time), but Linux only has 2.8.7 (Linux Mint 13/Ubuntu 12.04) or 2.8.12.2 (with kubuntu backports or Linux Mint 17/Ubuntu 14.04).  This project only requires 2.8, so 2.8.12.2 for Windows is sufficient.

Open the cmake‑2.8.12.2‑win32‑x86.exe download file and accept the User Control Access if asked.  Click through and accept the license.  On the Install Options dialog, select the Add CMake to the system PATH for all users or current user as desired, and the Create CMake Desktop Icon if desired.   Continue clicking through and finally click Finish.

Memory Testing Issue

I spent the day yesterday installing a new SSD (Solid State Drive).  After installing the OS (the same Linux Mint 13 KDE 64-bit) and transferring my previous configuration (home directory), the version of Mint 13's KDE was upgraded from version 4.8.5 to 4.10.5 using the Kubuntu backports repository.  Along with KDE 4.10.5 came a slightly new version of the Qt libraries (from 4.8.1 to 4.8.2) and CMake (2.8.7 to 2.8.9).  While the CMake change had no effect, the new Qt libraries caused the memory tests to fail.

The reason for the failures was due to the error suppression file containing specific references to Qt 4.8.1, which obviously didn't match the errors produced when using Qt 4.8.2.  Changing all the "4.8.1" string to "4.8.2" allowed the memory test to pass.  Instead of having separate suppression files for each version of Qt, the suppression file was changed to a CMake configure input file where CMake fills in the current Qt version.

Testing this change with an installed version of Qt 4.8.4 (Qt 4.8.5. is now the latest version of the Qt 4.8 series) did not work because of two issues.  The first was that this version of Qt was located in a different path.  The suppression input file was modified to also get the directory of Qt filled in by CMake.  The second was that Qt 4.8.4 produced a few additional memory errors.  These errors were added to the suppression input file and do not cause any issues when testing with Qt 4.8.2.

In addition to these changes, a temporary regtestn script was added, similar to memtestn, that tests the expression tests and the translator tests that are working with the new translator routines.  A temporary batch file regtestn.bat was also added, however, because of the limitations of DOS batch files, it couldn't easily be restricted to only test the first five translator tests.

[commit 3bb45e3ced]

New Git Repository Tagging Convention

The error highlighting implementation is now complete and it is time for a development release.  I made the decision to change the naming convention of repository tags from releaseX.X.X to vX.X.X, which is the convention used by many other projects under git revision control (like the git source repository itself).  All the "release" named tags have been replaced with the new "v" named tags.  These can be removed from a local repository using the command git tag -d `git tag -l release*` (backward single quotes) or the repository can be re-cloned.

To support this change, the CMake build configuration file CMakeLists.txt was modified for this naming convention.  A change was also required in the building of the version string in the command line class, which previously added seven to the release string pointer, seven being the length of the "release" part of the version string.  This could have simply been changed to one, the length of the "v" part of the string, but instead a little code was added to look for the start of the version number part of the string (by using a regular expression) so it doesn't matter what string precedes the version number.

The change in tag names will not cause a problem when building one of the archive files downloaded for a given tag because CMake will generate the version string being that the git repository will not be available.  Though the version announced as being built will still have the "release" string in the name.

However, if building at an older tag with the new tag naming convention, then these changes are needed, which is not an issue with any of the versions prior to 0.2.  CMake will not complain from versions 0.2-1 to 0.2-6 but the version number output will be messed up.  The changes need to be applied manually.  Starting with the final version 0.2.0 through the 0.3.X versions, the changes can be applied by git using the command git cherry-pick fa89 command where fa89 is the abbreviated commit ID of the commit with the changes.  To preserve this commit, a new branch can be created using the command git checkout -b xxx where xxx is the desired branch name.

Finally, previous blog entries were edited to reflect the new tag naming convention.  All blog previously given the Pre-Release blog tag was given the Tag blog tag.  Major releases still contain the Release blog tag (and not the Tag blog tag so they can be differentiated).

[commit fa89de8a0d]

GUI – Icons and Resources

The next item for the GUI is to add items to the tool bar, which has already been created, but is currently only blank.  Unlike the menu items which are text, the tool bar items are icons.  It is convenient if the icons are part of the application file and not separate files that must be included to run and must be loaded by the application.

This is accomplished by converting the icon files into C++ source files that are then compiled and linked into the application.  The Qt Resource Compiler (RCC) is used to convert the icon files to source files.  All the resources for the program are listed in an XML resource (.qrc) file.  QtCreator makes it easy to create and maintain these resource files.

To create the resource file, the new file wizard was again utilized.  Under Files and Classes the Qt item (lower-left) and Qt Resource file (upper-right) was selected.  On the next Choose the Location dialog, the Name: field was set to ibcp.qrc.  On the next Project Management dialog, the defaults were selected (which was set to git).  Once finished, QtCreator opened up a specific resources editing window.

To start simple, an application icon was given to the program, which will appear in the upper corner of the application window and on the task bar of the OS.  Up to now, a generic icon was being used (an X icon on Linux/KDE and a generic program icon on Windows).  An icon file was created by the name ibcp.png and placed in the new images sub-directory.  The image chosen and created consists of two lightning bolts, which represents the letter I, two to represent Interactive and Incremental, for the type of BASIC compiler being created.  The lightning bolt itself represents speed, since the goal of this project is to make a fast interactive BASIC compiler.

To add this new icon to the resource file, the Add button at the bottom resource editing window was clicked and Add Prefix was selected.  The Prefix: field, which defaulted to /new/prefix1 was cleared (which set it to a single slash).  The Add/Add Files was then selected, which opened a file selection dialog.  The images/ibcp.png file was selected, which added the file to the resource list.

To assign this icon file to the application, in Designer, the MainWindow object was selected (upper-right panel) and under properties (lower-right panel), the ... button was clicked for the windowIcon property, which displayed a Select Resource dialog.  The images item (left-side) was selected, which displayed the ibcp.png icon (right-side), which was selected.

To finish, the building of the resources needed to be added to the CMake build file.  Resources are handled by the qt4_add_resources command that is added as part of the Qt4 CMake module.  This command is given a list of resource files (in this case ibcp.qrc) and produces a list of resource source files that are generated by RCC.  This list of generated source files was then added to the add_executable command.

[commit ba9ee1be2a]

Qt GUI Files and CMake

Previously, new header or source files were added to the list of header and source files in the CMake build file CMakeLists.txt.  Qt form files (with the .ui extension) and header files containing the Q_OBJECT macro are handled differently.

The Q_OBJECT macro is added to any class definition that contains Qt's C++ extensions for defining signals and slots, which are class sections in additional to the normal private, public and protected sections.  These are handled by Qt's Meta-Object Compiler (moc), which produces a special MOC source file from the header file.  For mainwindow.h, the special source file produced is moc_mainwindow.cxx, which then gets compiled and linked into the program.

In the CMake build file, this is handled by the qt4_wrap_cpp command that is added as part of the Qt4 CMake module.  It is given a list of MOC source files and produces a list of MOC output source files.  This output list is then specified as a dependency to the output executable.  When a header file is included in the MOC sources list, it does not also need to be specified in the list of [normal] header files.

Qt form files are generated as an XML like language.  This file needs to be converted into a class definition (within a header file) so that it can be used by the C++ code.  These conversions are handled by Qt's User Interface Compiler (uic), which produces a special header file from the form file.  For mainwindow.ui, the special header file produced is ui_mainwindow.h, which contains the Ui_MainWindow class.  This source file is then included by the mainwinow.h header file.

In the CMake build file, this is handled by the qt4_wrap_ui command.  It is given a list of form UI files and produces a list of user interface header files.  This output list is then specified as a dependency to the output executive.

All of the generated files are placed in the CMake build directory, the same directory where the auto-generated header files (from the awk scripts) are placed.  This directory (the project binary directory) is specified in the include_directories command, so that the C++ compiler can find all of these generated files.  It is also no longer necessary to specifically check for an in-source build to not add this directory because the conflict no long exists between the system string.h header file (not used) and project string.h header file (removed).

[commit f4a35bbab6] [commit 266022803b]

CMake Issues

The patch release number has not been updated for recent development tags.  There needed to be way to automatically keep the release numbers in the CMake build file up to date with to release number in the git repository (which is determined from the most recent tag).

To prevent this from happening in the future, the CMake file was modified to check the release numbers to the current tag in the Git repository.  Previously, if the Git program was found, the release string was obtained from Git using the git describe command, otherwise the release string was set to the release numbers specified in the CMake file.

The CMake file was modified to instead first set the release string to the release numbers.  If the Git program is found, then its release number is obtained and put into a temporary variable.  If the Git release number was obtained (it wouldn't be if no repository is present), then a check is made to made sure the release string matches the first part of the Git release number (using the string command with the REGEX MATCH operation).  If it doesn't match, then a fatal error is produced.  This will catch a mismatch after a new tag is added if the release numbers are not also  updated before changes are pushed to GitHub.

One other minor change was made to the CMake file.  If the build type contains an empty string, it is now set to "Release" so that it is not empty.  Though technically this is the same as an empty string, at least now when CMake is run, the "Build type:" message does not show nothing.

[commit c0c027c07b]

Qt Application – Main Function

Another convention of Qt applications is that the main() function goes in the main.cpp source file, so the ibcp.cpp source file was renamed (and the CMake build file was updated).

While reviewing the CMake documentation, I discovered that there is a specific FindGit module, so it is not necessary to use the more generic find_program command.  The CMake build file was updated to use the find_package with the FindGit module (by using the Git argument).  There is no specific module for finding the Awk program, so this will remain using the generic find_program command.

Note: For now on instead of saying the changes have been pushed to GitHub, the specific commit ID (short form) will be put at the bottom of the post with a direct link to the commit on GitHub that is associated with the post (instead of a generic link to the Git repository, which is on the right under Downloads).  The post will also be given the GitHub label.  Recent posts are being updated to this convention.

I also noticed that the patch version number in the CMake file hasn't been updated for recent development tags.  This is not an issue when building from a source directory with the Git repository, but is when building from downloaded archives from GitHub.  So to set things straight going forward, tag v0.2-5 was added with the correct patch number in the CMake file.

[commit 381d30da1a]

Minor Build And Test Issues

A build issue was discovered where CMake does not create a release string if the git command is present but the git repository is not (for instance when building from a downloaded archive).  The git describe command was returning an error and no release string.  CMake now detects this situation and sets the release string the same as if no git command is found.

A test issue was discovered on Windows when building from a downloaded archive, which contains Unix format files (newline only) and not DOS format files (CRLF).  When the program is run from the regression test script (the program builds fine), the output files are in DOS format, but the compares fail because the expected output files are in Unix format.  The cmp command was changed to the diff command, which has an option to ignore the difference in the line separators (the ‑w ignore white space option).

All these changes have been pushed to GitHub and because of the build and test issues found, new tag v0.2‑2 was added.  The changes to the Parser were complete (with the attempt to compile next) before the text stream detour and these other minor issues.

[commit 0e85c83d56] [commit 2be4bd2f91]

Building On Windows With Qt

In order to build the program (that now requires Qt), CMake needs to be able to find the Qt files.  It accomplishes this by looking for the Qmake executable (qmake.exe on Windows) even if it is not actually used, but its location is used to determine where Qt is installed.  To find the Qmake executable, CMake searches the directories in the execution path.

On Linux, the qmake executable is already in the standard directories.  On Windows, the directory for qmake.exe needs to be added to the execution path.  The instructions for adding a directory to the execution path was given in the post on October 20.  The directory C:\QtSDK\Desktop\Qt\4.8.1\mingw\bin needs to be added.  If using the MSYS command line, the directory /c/QtSDK/Desktop/Qt/4.8.1/mingw/bin needs to be added to the path (see post on October 7).

QtCreator can be used to access the git repository (see post on October 20).  To switch to the latest development branch (branch0.2 at the time of this post), the branch needs to retrieved from the repository on GitHub.  On the Tools menu, select Git and then Pull.  Only local branches can be checked out, so a local branch needs to be created.  On the Tools menu, select Git and then Branches....  Select branch0.2 under origin and click the Add... button.  Click OK on the next Dialog.  This will create local branch0.2, which can now be selected and checked out with the Checkout button.  Select Close to dismiss the Branches dialog.

To build, first select Run CMake on the Build menu and make sure the Generator is set to MinGW Generator (MinGW (x86 32bit)).  Now click the Run CMake button.  As mentioned previously, sometimes a bunch of errors occur the first time.  Trying a second time causes no errors.  If at any time there are problems running CMake, deleted every file in the qtcreator-build and try again.

There is a problem in running the regtest script in Windows XP when the build directory is under the current user directory under the C:\Documents and Settings\ directory.  The problem occurs because there are spaces in the directory name, which causes bash to incorrectly process the line.  There is no problem on Windows 7 because the user directories are under the C:\Users\ directory (which has no spaces).  There is also no problem if the build directory is under the user home directory within MSYS (again no spaces).  As for regtest.bat, this batch file requires the build to be performed in the source directory.  Also note that the new memory test script is not available on Windows.

Automatic Building For Debugging

When using Qmake with QtCreator, both Release and Debug builds are configured and it is easy to switch between the two.  CMake supports several build types including Release, Debug, Release With Debug Info and Minimum Size Release.  The default is blank (which is probably similar to Release, but definitely does not turn on debug information).  However, the CMake build types are not directly available in QtCreator except by specifying the CMAKE_BUILD_TYPE variable when running CMake.

During development it is obviously desirable to build the program with debug information.  The CMAKE_BUILD_TYPE variable could simply be set to Debug in the CMakeLists.txt file.  But then this would need to be changed when a release is made, so this is not a good solution.

Instead, the CMakeLists.txt file was setup to look for a CMAKE_BUILD_TYPE environment variable (CMake can access system environment variables).  If this environment variable is set, then the CMake variable is set to the environment variable unless it has already been set.  If the environment variable is not set, it behaves the way is did before.

This environment variable can be set in QtCreator by going to the Projects screen, selecting the Build Settings and adding this environment variable to the Build Environment with the desired Debug value.  The Release With Debug Info (RelWithDebInfo) could also be used, but can make stepping through the program confusing since most of same optimizations are turned on as with Release and the compiler can rearrange statements for efficiency (execution will appear to jump around) or optimize out variables (the values of which cannot be viewed).

[commit 7ee8e7483c]

Unique Release Number Implementation

To see if the git command is available, a find_program command was added to the CMakeLists.txt file, which sets the CMake variable PROGRAM_GIT.  An if command was also added that checks if this variable is set, which then executes the command using the  execute_process command for the describe sub-command in the project source directory setting the CMake variable ibcp_RELEASE_STRING with the resulting string.  The option OUTPUT_STRIP_TRAILING_WHITESPACE was needed to remove the trailing newline.

If the git program was not found, then the ibcp_RELEASE_STRING variable is set to "v" followed by the major and minor release numbers separated by a period.  If the patch release number is less than zero (development tag), then the patch number is appended to the release string (the dash is present because the number is negative).  Otherwise, the patch number is appended with another period separator.  The final release string, from either source, is output to the CMake output log.

In implementing this if command, it was realized that it was not necessary to test the PROGRAM_GIT variable for the string to be equal to "PROGRAM_GIT‑NOTFOUND" as was done with the awk program because this is one of the tests performed by the CMake if command.  Therefore, the if command for the awk program was simplified.

A define for ibcp_RELEASE_STRING was added to the ibcp_config.h.in file (used to auto-generate ibcp_config.h) with the contents of the CMake variable surrounded by quotes, to form a string constant that can used in the source code.  The ibcp_version() function was modified to output this string constant instead of the major, minor and patch numbers.  The "v" part of the string is not output (because "version" is already being output).  Finally, the GPL header was removed when outputting the version number to be consistent with the output of other programs.

New branch0.2 was created.  The release string produced at this latest commit will be v0.1.16b-1-g1bba2c3, which shows the most recent tag (v0.1.16b), the number of commits beyond this tag (1) and the short commit ID (1bba2c3).  The "g" in front of this ID stands for git (other letters would stand for other software configuration management systems).

[commit 1bba2c335c]

Unique Release Numbers

With a new release numbering scheme defined, there needs to be way to get the current version number into the program for output with the -v command line option (and eventually in the Help/About box once the GUI is implemented).  The version number should also be unique during development since not every commit will be tagged.  The goals are:

1. Use the current tag if at a tagged commit
2. Represent when not at a tagged commit during development
3. Use the current release number assigned for archive downloads
4. Allow for developmental (dash) and patch (period) numbering

The inclusion of the third goal will be clear shortly.  It turns out that the exact desired release string can be obtained using the git describe command, which returns the name of the most recent tag.  When beyond the most recent tag, the number of commits beyond the tag plus the short form of the current commit ID is appended.

This works as desired when the git command is available and the git repository information is present, but for the third goal, the downloaded archives have no git information.  Since the download archives are only available at tagged commits, the release number set in the CMakeLists.txt file can be used and will match the tag at that commit (assuming these variables were set to the same values as the tag).

For the last goal, there are two cases, git repository information present and not present.  When making tags during development, the tag name format will be releaseX.Y‑Z (note the dash).  The git describe command will pick this tag name (and append the rest if beyond that tagged commit).  When the git repository information is not present, the major, minor and patch release numbers set in the  CMakeLists.txt file will be used.  To handle developmental (dash) numbering, negative patch numbers will be used.

Build Issues Discovered

While writing the procedures for building with QtCreator, some issues were discovered.  The first was with running CMake on Windows.  The first time it produces errors no matter which generator is selected.  It also appeared that adding "‑G "MSYS Makefiles" caused it to work, but adding this before still caused errors.  It turns out this was not necessary, simply clicking the Run CMake button a second time worked with no error.  The previous post about this was updated.

The next problem was when trying to use the included MinGW (with GCC 4.4) in the Qt SDK.  It was still trying to use the static linking, which is not supported in versions before GCC 4.5.  It turns out there were two problems.  First, the check to whether to add the static linking options should have been greater than 4.4, but was incorrectly less than 4.5.  Second, the add_definitions command used in the CMake file adds compiler options, not linker options.  The command add_target_properties should have been used with the LINK_FLAGS property option.

Due to these linking issues, the binaries posted on Sourceforge were not linked with static linking.  This is not an issue with Linux since the required libraries will be present.  However, for Windows, a missing DLL message will occur on a system without the required libraries.  Therefore, a new binary zip file was updated (labels 0.1.16a).  The update executable was actually tested on a Windows XP system without the require libraries this time. The sources and Linux binary were not updated.  If building from source, the required libraries will be present.  The repository on GitHub was updated with new tag release0.1.16a.

The final problem is in using the MinGW installed with the Qt SDK.  Even though the static linking problems were corrected, the included MinGW cannot (alone) be used the build the project.  The issue is that the awk utility is needed to create the auto-generated header files and there is not included awk utility with MinGW.  It is included with the MSYS package.

Project – CMake (Release)

It took a little extra time generating the release (it has been a while).  GitHub recommends that the project include both a README and LICENSE file, so these were also added to the project.  GitHub was updated yesterday and all the download files have been uploaded to Sourceforge today.

Since both Windows and Linux natively use different format text files (CRLF vs. newline for line separator), both sets of source files were uploaded.  The Windows download file ibcp_0.1.16‑src.zip is in zip format and the Linux download file ibcp_0.1.16‑src.tar.gz is in tar format compressed with gzip, use the tar xzf <filename> command to uncompress and untar the file with a single command.

The binary download files that were uploaded contain not only the executable program, but also the test input files, expected result files and regression test scripts.  Again the included text files are in the correct file format for the platform.  The Windows binary download also contains a DOS batch file for running the regression tests.  Nothing needs to be installed to run the program and regression tests.

CMake Updated For Test Programs

The old make file also built the various test programs residing in the test sub-directory.  The CMake build system was updated to also build these test programs.  This required quite a bit of experimentation to get working, but the final solution was rather simple.  First, each of the test programs an add_executable command was added to CmakeLists.txt with the list of the source files required to build the program along with any dependent header files.

To create the new make tests target required an add_custom_target command naming the target (tests) and specifying the test programs that this target is dependent on using the DEPENDS option.  However, there was a problem where the test programs were built with the standard make command (the same as make all) in addition to when the make tests command was issued.  This problem was resolved by adding the EXCLUDE_FROM_ALL option to each of the test programs add_executable command.

Each of the test programs were tested to verify that they produced the same output on all three platforms.  Several of the test programs were updated to achieve this, and the expected output files were updated accordingly.  Hit Continue... below for details on the changes made to the test programs.

Now that all the CMake issues have been resolved, it is time to make official release 0.1.16.  It's going to take a little time to prepare the release notes, merge branch0.1.16 to master, generate all the archive files for uploading, etc..  In the mean time, the latest changes have been pushed to GitHub and tagged v0.1.16‑pre‑2.  The should be close to the actual release, since none of the core program files are expected to change.