wpkg 0.9.2 available
wpkg 0.9.2 is now available! The new packager system includes a 100% coverage test of the advgetopt class. This allowed me to find out why the lone "-" wasn't working right, and a couple of other major bugs: the use of an option which requires exactly one parameter would return the very first one found from anywhere (the configuration file, the environment variable, or the command line) and it properly handles the case of a no name option which I had never tested before (this is a valid case for default parameters.)
The class also offers additional tests that are useful to catch mistakes in the list of options passed to it from a programmer building her own command line tool. These allowed me to find out that pretty much all the commands inside the tools directory had an invalid duplicate 'h' option. Other tests include duplicate default options and invalid long name (i.e. it must be define in several different cases and it must be at least 2 characters.)
You can find more details about these fixes in the wpkg 0.8.4 blog post I made earlier.
As I was working on the advgetopt I noticed a problem in the case insensitive string compare: the compare was being done with UTF-8 characters as if the locale was UTF-8 which it may or may not be. I changed the algorithm by adding a function in the libutf8 library to first transfom the UTF-8 characters to a wchar_t character and then calling toupper() on each one of these characters. Just like under Microsoft Windows, I do transform the characters as if they were to always fit in a UCS-2 characters. In other words, characters over 0x10000 (64Kb) do not get capitalized. This should not be a problem because we are primarily trying to duplicate the functionality of the NTFS file system which is till used by Microsoft Windows, plus this test is there to prevents two files with the same name but different case to be added in a package. It does not prevent you from using any valid filename. Needless to say, by fixing this bug you may get some errors while building your packages because all of a sudden the code will detect files that are the same and were not before. However, best of all, the other way around was true too: you may get files that clashed before, even though they shouldn't have, to work together as expected.
I fixed some errors in messages and added quite a bit of doxygen documentation to different places (libutf8 and advgetopt are expected to be function complete.)
I noticed errors in the messages as I was working on a new version of the configuration scripts. This led me to notice that I was not warning about some errors while running some scripts even though I was supposed to do so.
As I was automating the compiling under Microsoft Windows, that is, to run a script to get all six files / packages compiled and packaged, I noticed that I was still using win32 and win64 in the package names. I changed to that to mswindows as it is supposed to be in newer packages. I also noticed that I was still using sunos for the Solaris Operating System, I fixed that with the name we expected to use: solaris.