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]
Wednesday, October 24, 2012
Finding Memory Leaks (Linux)
QtCreator can be used to find memory leaks using the Analyze mode. This requires the valgrind program, which can be installed via the valgrind package on Ubuntu based distros. Unfortunately it looks like this program has not been ported to Windows (MinGW), so Windows developers are out of luck (at least when using MinGW with the Qt SDK).
In order to use valgrind, the program to check must be compiled with debugging information. To do this with CMake under QtCreator, in the Run CMake dialog, the Arguments line needs to be set to ‑DCMAKE_BUILD_TYPE=Debug. This is a nuisance because it needs to be done every time CMake is run the first time and there appears to be no way to automate this inside QtCreator. So an alternate scheme was devised using CMake (will be described in the next post).
Once Analyze mode is selected (by the icon on the side panel or Ctrl+6), the Analyzer panel will appear. In this panel, the mode needs to be changed from QML Profiler to Valgrind Memory Analyzer. The program is started using the start (play) icon (left side of Analyzer panel toolbar). Once the program ends, any memory issues will be reported.
After using the Analyzer to learn about list element deallocation, I thought it might be a good idea to check the ibcp program for any memory issues. There is already an implementation to detect token memory leaks accomplished by overloading the new and delete operators for the Token structure, but there are many other memory allocation operations in the program.
So this process was started for each parser, expression and translator test. For each, the run arguments were set (Projects page, Run Settings) and the Analyzer was run. This were no memory issues on the parser tests, however, some problems were found on the translator tests, which will be discussed in following posts.
In order to use valgrind, the program to check must be compiled with debugging information. To do this with CMake under QtCreator, in the Run CMake dialog, the Arguments line needs to be set to ‑DCMAKE_BUILD_TYPE=Debug. This is a nuisance because it needs to be done every time CMake is run the first time and there appears to be no way to automate this inside QtCreator. So an alternate scheme was devised using CMake (will be described in the next post).
Once Analyze mode is selected (by the icon on the side panel or Ctrl+6), the Analyzer panel will appear. In this panel, the mode needs to be changed from QML Profiler to Valgrind Memory Analyzer. The program is started using the start (play) icon (left side of Analyzer panel toolbar). Once the program ends, any memory issues will be reported.
After using the Analyzer to learn about list element deallocation, I thought it might be a good idea to check the ibcp program for any memory issues. There is already an implementation to detect token memory leaks accomplished by overloading the new and delete operators for the Token structure, but there are many other memory allocation operations in the program.
So this process was started for each parser, expression and translator test. For each, the run arguments were set (Projects page, Run Settings) and the Analyzer was run. This were no memory issues on the parser tests, however, some problems were found on the translator tests, which will be discussed in following posts.
List Class Replacement (Begin)
The List class was the first implemented for this project, so it is fitting that it will be the first to be replaced with the transition to Qt. Qt's list class is named QList. The functionality is not much different then the home grown List class, though most of the member functions have different names.
The approach being used was to first replace all cases of List with QList and then search for each List class member function name and replace it with QList's version. In some cases, the code needs to be written a bit since the QList functionality is slightly different. For example, while QList also has a first() function, it must not be called if the list is empty (must check if it is empty first), while the List class first() function allows for an empty list (returning a null pointer).
The first complication came in how to deallocate items in the QList. The question was, does this happen automatically when leaving scope, is deleted or via QList's clear() member function. Neither was the case where the list is a list of pointers to allocated elements. Each element needs to be deleted (same as the case with the List class).
A small test program was written to evaluate and confirm this behavior. As part of this evaluation, a method to detect memory leaks was employed that is kind of built into QtCreator (at least on Linux). This lead to quite a few detours, which will be the subject of the posts that follow...
The approach being used was to first replace all cases of List with QList and then search for each List class member function name and replace it with QList's version. In some cases, the code needs to be written a bit since the QList functionality is slightly different. For example, while QList also has a first() function, it must not be called if the list is empty (must check if it is empty first), while the List class first() function allows for an empty list (returning a null pointer).
The first complication came in how to deallocate items in the QList. The question was, does this happen automatically when leaving scope, is deleted or via QList's clear() member function. Neither was the case where the list is a list of pointers to allocated elements. Each element needs to be deleted (same as the case with the List class).
A small test program was written to evaluate and confirm this behavior. As part of this evaluation, a method to detect memory leaks was employed that is kind of built into QtCreator (at least on Linux). This lead to quite a few detours, which will be the subject of the posts that follow...
Tuesday, October 23, 2012
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]
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:
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.
- Use the current tag if at a tagged commit
- Represent when not at a tagged commit during development
- Use the current release number assigned for archive downloads
- Allow for developmental (dash) and patch (period) numbering
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.
New Release Numbering Scheme
In light of the two recent problems discovered after Release 0.1.16 was made, a new release and branch numbering scheme is needed. Technically, the third number on the release number should be for patches of a release. Instead of using 0.1.16a and 0.1.16b, 0.1.16.1 and 0.1.16.2 could have been, but wasn't because the version numbering is currently only setup for major, minor and patch numbering, so the "a" and "b" were used (though it wasn't setup for this either).
As for branches, there is no reason to have a branch for every patch number (like with branch0.1.14, branch0.1.15 and branch0.1.16), though these were not really patches though the patch number was increasing. Therefore, going forward there will only be branch0.2 for the developmental release 0.2 series. As something worthwhile is completed, a tag with this number plus a dash number will be added, for example 0.2-1, 0.2-2, etc. This will be the equivalent of the "-pre-" (and "-dev-" before that) that were used previously.
When the release series is completed, the release will be given the number 0.2.0. (It's too early in development to worry about release candidates, but when that time comes, the "-rcX" format will be used.) Any patches needed for a given release will then be given patch numbers 0.2.1, 0.2.2, etc. Now to generate a unique version release number at each commit taking into account using the current tag for a tagged release...
As for branches, there is no reason to have a branch for every patch number (like with branch0.1.14, branch0.1.15 and branch0.1.16), though these were not really patches though the patch number was increasing. Therefore, going forward there will only be branch0.2 for the developmental release 0.2 series. As something worthwhile is completed, a tag with this number plus a dash number will be added, for example 0.2-1, 0.2-2, etc. This will be the equivalent of the "-pre-" (and "-dev-" before that) that were used previously.
When the release series is completed, the release will be given the number 0.2.0. (It's too early in development to worry about release candidates, but when that time comes, the "-rcX" format will be used.) Any patches needed for a given release will then be given patch numbers 0.2.1, 0.2.2, etc. Now to generate a unique version release number at each commit taking into account using the current tag for a tagged release...
Monday, October 22, 2012
Regression Test Script Problem
Another problem was discovered, this time with the regtest script. For convenience, my PATH variable contains the current working directory ("."), so I didn't notice this problem. By default (and for safety), the PATH variable does not contain the current working directory. So the regtest script fails to find the "ibcp" program.
Therefore, regtest (actually regtest.in) was modified with a "./" in front of ibcp so that the regtest script will run the program in the current working directory. No new files were uploaded to Sourceforge, but a new commit and tag release0.1.16b was pushed to GitHub. The Windows batch file regtest.bat is not affected since Windows by default will look in the current working directory for a program.
Therefore, regtest (actually regtest.in) was modified with a "./" in front of ibcp so that the regtest script will run the program in the current working directory. No new files were uploaded to Sourceforge, but a new commit and tag release0.1.16b was pushed to GitHub. The Windows batch file regtest.bat is not affected since Windows by default will look in the current working directory for a program.
Sunday, October 21, 2012
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.
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.
Saturday, October 20, 2012
Running in QtCreator
After the program has been built it can be run or debugged in QtCreator. For now, command line arguments need to be added before running the program, otherwise it will only output a usage message.
Command line arguments are set on the Projects screen (the Projects icon on the side or Ctrl+5) by selecting the Run Settings button along the top of the screen. For example, under Run, enter ../thunder422‑ibcp/test/translator01.dat to run the first translator test (assuming the default directories were used up to now).
Again there are multiple ways to run the program (play icon on lower side, Ctrl+R, Run on the Build menu). Same for running in the debugger; though note that in order to trace through the program, a breakpoint needs to be set first or the program runs (in the debugger) until it exits.
Command line arguments are set on the Projects screen (the Projects icon on the side or Ctrl+5) by selecting the Run Settings button along the top of the screen. For example, under Run, enter ../thunder422‑ibcp/test/translator01.dat to run the first translator test (assuming the default directories were used up to now).
Again there are multiple ways to run the program (play icon on lower side, Ctrl+R, Run on the Build menu). Same for running in the debugger; though note that in order to trace through the program, a breakpoint needs to be set first or the program runs (in the debugger) until it exits.
Building With QtCreator
Now that it has been configured for all the tools, everything can be done inside QtCreator. Start QtCreator and select New Project... on the File menu. In the New dialog select Project from Version Control and then Git Repository Clone. After clicking the Choose... button, the git repository can be selected. For Clone URL: enter https://github.com/thunder422/ibcp. If desired, change the Checkout path. The Checkout directory will default to thunder422-ibcp. Click the Next button and the repository will be cloned.
Once finished, the CMake Wizard dialog appears asking for the Build Location. The default directory can be used. The next dialog of the wizard is to Run CMake. On Windows, the Generator: needs to be changed to MinGW Generator (MinGW (x86 32bit)) assuming MinGW 4.4 was installed with Qt SDK, otherwise this is the only generator available.
Clicking the Run CMake button at this point causes a bunch of errors.Adding ‑G "MSYS Makefiles" to the Arguments: line appears to resolve the problem. Adding this before clicking the Run CMake button the first time does not make it work though clicking a second time does. Clicking the Run CMake button a second time works. I have no explanation for this at the moment. This is a similar problem that caused issues with NetBeans and CMake. On Linux, clicking the Run CMake button is all that is necessary.
Adding ‑DCMAKE_BUILD_TYPE=Debug to the Arguments: line turns on debug information to that the debugger can be used. After CMake is run, the program can be built. There are a number of ways to begin the build, including the Build menu, Ctrl+B and the hammer looking icon at the bottom of the tool bar on the left side. The build can be monitored by clicking the 4 Compile Output button along the bottom of the screen.
Once finished, the CMake Wizard dialog appears asking for the Build Location. The default directory can be used. The next dialog of the wizard is to Run CMake. On Windows, the Generator: needs to be changed to MinGW Generator (MinGW (x86 32bit)) assuming MinGW 4.4 was installed with Qt SDK, otherwise this is the only generator available.
Clicking the Run CMake button at this point causes a bunch of errors.
Adding ‑DCMAKE_BUILD_TYPE=Debug to the Arguments: line turns on debug information to that the debugger can be used. After CMake is run, the program can be built. There are a number of ways to begin the build, including the Build menu, Ctrl+B and the hammer looking icon at the bottom of the tool bar on the left side. The build can be monitored by clicking the 4 Compile Output button along the bottom of the screen.
Post Qt Installation Setup (Windows)
After installation of the Qt SDK, the tools (git, MinGW and CMake) need to be integrated with QtCreator. On Linux, no further configuration is needed as all tools will be located where QtCreator can find them. However, on Windows, this is not the case.
For git, the binary directory for the git tools need to be in the execution path. On Windows XP, right-click on My Computer and select Properties. On the Advanced tab, click the Environment Variables button. On the lower pane under System Variables, find and selected the Path variable. Click Edit and add C:\Program Files\Git\bin somewhere on the Variable value line (make sure to add the semicolon separator). On Windows 7 the instructions are similar. Start by right-clicking Computer and select Properties. Now select Advanced system settings, go to the Advanced tab and follow the same instructions except add C:\Program Files (x86)\Git\bin to Path.
Now start QtCreator. QtCreator should have automatically found the external MSYS/MinGW 4.6.2 previously installed. On the Tools menu select Options, go to the Build & Run page, and select the Tool Chains tab. Under Auto-detected there will be an entry Mingw as a GCC for Windows targets (if the MinGW 4.4 was installed as part of Qt SDK) and an entry MinGW (x86 32bit), which is the previously installed MinGW 4.6.2. The g++ path can be seen by selecting this entry, which should show C:\MinGW\bin\g++.exe.
For the final tool, CMake, select the CMake tab next to Tool Chains. If the correct path was added to the Path under Environment Variables, the path to cmake.exe will already be set. Otherwise, click Browse and find cmake.exe, which will be found under C:\Program Files\CMake 2.8\bin\cmake.exe (Windows XP) or C:\Program Files (x86)\CMake 2.8\bin\cmake.exe (Windows 7) if CMake was installed in the default location. Don't select cmake-gui.exe.
Now it's time to see if QtCreator is able to build and debug the ibcp program before we start any Qt related modifications.
For git, the binary directory for the git tools need to be in the execution path. On Windows XP, right-click on My Computer and select Properties. On the Advanced tab, click the Environment Variables button. On the lower pane under System Variables, find and selected the Path variable. Click Edit and add C:\Program Files\Git\bin somewhere on the Variable value line (make sure to add the semicolon separator). On Windows 7 the instructions are similar. Start by right-clicking Computer and select Properties. Now select Advanced system settings, go to the Advanced tab and follow the same instructions except add C:\Program Files (x86)\Git\bin to Path.
Now start QtCreator. QtCreator should have automatically found the external MSYS/MinGW 4.6.2 previously installed. On the Tools menu select Options, go to the Build & Run page, and select the Tool Chains tab. Under Auto-detected there will be an entry Mingw as a GCC for Windows targets (if the MinGW 4.4 was installed as part of Qt SDK) and an entry MinGW (x86 32bit), which is the previously installed MinGW 4.6.2. The g++ path can be seen by selecting this entry, which should show C:\MinGW\bin\g++.exe.
For the final tool, CMake, select the CMake tab next to Tool Chains. If the correct path was added to the Path under Environment Variables, the path to cmake.exe will already be set. Otherwise, click Browse and find cmake.exe, which will be found under C:\Program Files\CMake 2.8\bin\cmake.exe (Windows XP) or C:\Program Files (x86)\CMake 2.8\bin\cmake.exe (Windows 7) if CMake was installed in the default location. Don't select cmake-gui.exe.
Now it's time to see if QtCreator is able to build and debug the ibcp program before we start any Qt related modifications.
Installation For Qt Development
On Windows, when installing the Qt SDK, select Custom then on the Select Components dialog, unselect the following under Documentation: Harmattan, Qt Simulator, Symbian, and Qt Mobility; under APIs: Qt Mobility APIs and Qt Quick Components for Symbian; and under Development Tools: Harmattan, Simulator, Symbian Toolchains, under Desktop Qt: Qt 4.7.4 (Qt 4.8.1 will be used). Under Miscellaneous, it is unnecessary to select MinGW 4.4 (the previously installed MSYS/MinGW 4.6.2 will be used, see here for instructions). Also, the Qt Examples are not necessary but can be left in.
These selections will decrease the amount to download when using the on-line installer. Once installed, any of the unselected components can be added using the Maintain Qt SDK program under the Qt SDK program group using the Package manager. The Default installation can also be used Once installed, QtCreator needs to be connected to our tools (git, MinGW and CMake; see next post).
On Linux, the download installers can be used with the same selections as above (make sure the correct installer versions are downloaded, 32-bit or 64-bit to match the version of Linux). On Ubuntu 12.04 based distros (for example Linux Mint 13), it is not necessary to install the Qt SDK as the packages needed for Qt development are in the Ubuntu repositories. Most of the Qt libraries should already be installed (especially if KDE is being used since it was developed using Qt). The only additional packages that need to be installed are qtcreator, libqt4‑dev, qtcreator‑doc and qt4‑doc (use the sudo apt‑get install command or the package manager). The version of QtCreator installed from the repositories is the same as in the current Qt SDK, specifically 2.4.1.
These selections will decrease the amount to download when using the on-line installer. Once installed, any of the unselected components can be added using the Maintain Qt SDK program under the Qt SDK program group using the Package manager. The Default installation can also be used Once installed, QtCreator needs to be connected to our tools (git, MinGW and CMake; see next post).
On Linux, the download installers can be used with the same selections as above (make sure the correct installer versions are downloaded, 32-bit or 64-bit to match the version of Linux). On Ubuntu 12.04 based distros (for example Linux Mint 13), it is not necessary to install the Qt SDK as the packages needed for Qt development are in the Ubuntu repositories. Most of the Qt libraries should already be installed (especially if KDE is being used since it was developed using Qt). The only additional packages that need to be installed are qtcreator, libqt4‑dev, qtcreator‑doc and qt4‑doc (use the sudo apt‑get install command or the package manager). The version of QtCreator installed from the repositories is the same as in the current Qt SDK, specifically 2.4.1.
Preparing For Qt Development
Qt has its own IDE (Integrated Development Environment) called QtCreator. Qt also requires all the various Qt libraries as well as Qt header files and several utilities. Qt has its own make system called Qmake, but QtCreator is also compatible with CMake, so Qmake won't be used.
For Windows, the best way to start is to simply install the Qt SDK (Software Development Kit) that contains and installs all the necessary programs and files. The current SDK, version 1.2.1, which contains Qt libraries version 4.8.1 and QtCreator version 2.4.1 as well as MinGW compiler suite. However, the version of MinGW installed contains an older GCC, version 4.4. Although it can easily be made to work with an existing MSYS/MinGW installation like the one the project has been using based on GCC 4.6.2.
Several choices of installers are available, a small on-line installer and a very large off-line installer. The off-line installer has the advantage of quick reinstalls. However, the on-line installer only downloads the components selected during installation so potentially there is much less to download (more can be downloaded and installed later if needed). Many of the components are unnecessary when strictly used for desktop development (for example, all the mobile development files can be ignored). Next post, installation...
For Windows, the best way to start is to simply install the Qt SDK (Software Development Kit) that contains and installs all the necessary programs and files. The current SDK, version 1.2.1, which contains Qt libraries version 4.8.1 and QtCreator version 2.4.1 as well as MinGW compiler suite. However, the version of MinGW installed contains an older GCC, version 4.4. Although it can easily be made to work with an existing MSYS/MinGW installation like the one the project has been using based on GCC 4.6.2.
Several choices of installers are available, a small on-line installer and a very large off-line installer. The off-line installer has the advantage of quick reinstalls. However, the on-line installer only downloads the components selected during installation so potentially there is much less to download (more can be downloaded and installed later if needed). Many of the components are unnecessary when strictly used for desktop development (for example, all the mobile development files can be ignored). Next post, installation...
New Focus – Introducing Qt
When this project was started, the plan was to first develop all the internal routines (parser, translator, recreator, etc) and wrap a simple command line interface around it initially for testing before tackling a modern interface (GUI). I even went as far as starting to learn about using the Console mode on Windows (though this couldn't be used on Linux). That was the purpose in parsing immediate commands.
Over the past year or so, I have been learning and using Qt, a cross-platform application framework (and it is Open Source). With Qt, it is fairly easy to develop programs with a sophisticated GUI, plus it does a whole lot more. So instead of fooling with some antiquated command line interface, the project will be transitioned over to using Qt. This desire accelerated after discovering the Basic-256 program early this year. This program is a great platform for teaching programming (was formally called Kid-Basic). This program also uses Qt.
It is not totally clear all what is necessary for this transition to Qt, but several items come to mind. The classes implemented towards the beginning of the project, the List and Stack classes, will be removed and the Qt equivalents will used in their place. Though not necessary, variable and function names will be changed to the Qt way of naming. The exceptions used during initialization will be removed as there are no exceptions in Qt.
Since this will be a major change in development, the Release 0.1 series will be concluded and development of the Release 0.2 series will begin. The change in direction mentioned with Release 0.1.15 will continue after the transition to Qt. First though, the computer needs to set up for Qt Development...
Over the past year or so, I have been learning and using Qt, a cross-platform application framework (and it is Open Source). With Qt, it is fairly easy to develop programs with a sophisticated GUI, plus it does a whole lot more. So instead of fooling with some antiquated command line interface, the project will be transitioned over to using Qt. This desire accelerated after discovering the Basic-256 program early this year. This program is a great platform for teaching programming (was formally called Kid-Basic). This program also uses Qt.
It is not totally clear all what is necessary for this transition to Qt, but several items come to mind. The classes implemented towards the beginning of the project, the List and Stack classes, will be removed and the Qt equivalents will used in their place. Though not necessary, variable and function names will be changed to the Qt way of naming. The exceptions used during initialization will be removed as there are no exceptions in Qt.
Since this will be a major change in development, the Release 0.1 series will be concluded and development of the Release 0.2 series will begin. The change in direction mentioned with Release 0.1.15 will continue after the transition to Qt. First though, the computer needs to set up for Qt Development...
Friday, October 19, 2012
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.
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.
Wednesday, October 17, 2012
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.
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.
Subscribe to:
Posts (Atom)