Sunday, June 14, 2015

Build fixes for different gcc distributions under Windows

I've spent most of the day today fixing various compilation issues for the three most often used distributions of gcc under Windows: TDM-GCC, mingw-w64 and the "classic" MinGW trying to ensure that the upcoming 3.0.3 release (as well as the current master) builds out of the box with all of them using all the common build scenarios. TDM-GCC and mingw-w64 required just one minor fix for g++ 4.9.2 which started providing clang-like __has_include() except with different (and IMHO completely useless) semantics, so we just have to ensure that we don't use it with gcc even if it is available which was easy to do and actually had been already done on master.

However things were much more interesting with MinGW. The main problem with it was that it couldn't be used to build wxWidgets with -std=c++11 option (nor -std=c++98 one, but almost nobody ever used this one anyhow) nor, even worse, even use this option when compiling applications using wxWidgets as it broke compilation of wxWidgets headers. There always was a simple workaround of using -std=gnu++11 option instead, but it only was simple once you knew about it, which wasn't the case for most of first-time wxWidgets users who ran into it. So I finally decided to make -std=c++11 work as well and now it does, even though this wasn't simple nor pretty.

The summary is that now building with all 3 compilers with and without -std=c++11 works. And, as a side effect of this, I also fixed some (mostly harmless) warnings so that building with MinGW and mingw-w64 now doesn't give any -- at least in the configurations I tested. TDM-GCC is pickier (which is probably a good thing) and still gives quite a few warnings, so using -Wno-unused-value in CXXFLAGS with it is recommended: with this option only a couple of warnings in 3rd party code remain.

Of course, there are too many combinations for me to have tested all of them: 2 branches (3.0 and master), C++11 and C++98, static and shared, Unicode and ANSI, STL and not-STL already give 96 builds to test and there are other options too. So, before I spend too much time congratulating myself, it would be great if people could actually test the build configurations they use and are interested in and report if there are any (and especially any new) problems with them as I'm sure I must have also broken something with so many changes. I'm just not sure what, yet -- please let me know!

Tuesday, April 07, 2015

Validating XRC


If you write your XRC files
by hand (which is probably relatively rare as most people prefer to edit them visually, but it does happen), and if you are human (which is probably not so rare), you are bound to make mistakes in them. Some of these mistakes result in invalid XML which give errors when loading the XRC file, some of them are not a big deal and are just ignored by the XRC parser, but some others can result in the layout mysteriously not working as expected, which can be annoying. Validating XRC files, i.e. verifying that they conform to the scheme describing all the valid XRC elements, allows to avoid all these problems at once, so it is strongly recommended to do it -- and this post will explain how, in details.


To validate them you need two things: a schema and a tool using it. The schema exists in our repository since October 2013 and is also available at the public URL As for the tools, anything supporting compact RELAX NG schema syntax can work, but in practice this seems to limit the choices either to the online validator at (Edit: this validator can't be used for validating XRC currently as RELAX NG support seems to be broken) or the original command-line validator, written by James Clark, one of the persons behind RELAX NG, called Jing, and the offline version is, unsurprisingly, much more useful as it can be integrated into the build process or used as part of pre-commit hook checks easily, so this is the one we are going to look at.
The latest Jing release is available from Google Code, but as the entire site will be closing soon, it might not work any longer by the time you are reading this, so here is the smaller and more up-to-date version. It is completely standalone and requires just a working Java installation, you can put the JAR file anywhere you want and simply run
$ java -jar /full/path/to/jing/jar
(in spite of the dollar sign indicating the Unix prompt, this works under Windows, too). The basic Jing command line syntax is just the schema file followed by any number of files to validate, however XRC schema uses the compact syntax which has to be explicitly selected by its -c option, so in the simplest case the full command line would look like
$ java -jar jing.jar -c $WXWIN/misc/schema/xrc_schema.rnc myfile.xrc
where WXWIN environment variable is supposed to contain the full path of your wxWidgets installation.
As an aside, it is also possible to avoid hard coding the path to the XRC schema, which may be important to make the validation step work on different machines. The natural way to do it would be to just use the canonical URI instead of the path to the schema, i.e. but currently this doesn't work, seemingly because of a bug in Jing handling HTTP-to-HTTPS redirections. The following command does work:
$ java -jar jing.jar -c myfile.xrc
but still has two problems: first, the URI is, formally speaking, wrong as it should be using "http" schema. Second, and probably more importantly in practice, it can be slow as the file needs to be downloaded from network every time. To fix this problem, an XML catalog mapping the canonical URI to a local file can be used. I won't pretend to know much about XML catalogs (because I don't), but here is a minimal one that can be used to set up the correct redirection:
If you save the above file as catalog.xml and adjust the value of the uri attribute to contain the correct path to xrc_schema.rnc on your machine (notice that triple slashes are needed), you should be able to use
$ java -jar jing.jar -C catalog.xml -c myfile.xrc

Using (or not) Custom XRC Elements

After the setup describe above you can use the standard schema xrc_schema.rnc to validate the contents of all the standard XRC elements, such as <sizeritem> or <object class="wxButton">. However any custom elements are simply ignored by default because the standard schema has no knowledge of them. Of course, you might not have any custom XRC elements at all. In this case, you should use xrc_schema_builtin_only.rnc, located in the same $WXWIN/misc/schema directory of your wxWidgets installation, to forbid any of them from appearing. There is no canonical URI for it, so you should simply pass full path to it on Jing command line.
The more interesting case is when you do define some custom XRC handlers. In this case using xrc_schema_builtin_only.rnc would result in errors about invalid value of attribute "class" for all your custom elements, so you need to define a custom schema describing just them. An example of doing it is shown in misc/schema/README, but here is an even simpler custom schema:
This schema allows appearance of a custom Frobnicator window-like (because of stdWindowProperties inclusion) element which can have one specific (but optional, because of the trailing *) num_times attribute, i.e. would validate the following XRC fragment: if you issue
$ java -jar jing.jar -C catalog.xml -c frob.rnc frob.xrc
command. Of course, the same fragment would also be accepted by the standard schema, the real benefit of using a custom one is that typos in either "Frobnicator" or "num_times" would be detected only by the latter.

TL;DR Summary

Your easy guide to XRC validation:
  1. Download jing.jar
  2. For one-time validation of only standard XRC elements just run
    $ java -jar jing.jar -c myfile.xrc
  3. For repeated use, download XML catalog, edit the file path in it and run
    $ java -jar jing.jar -C catalog.xml -c myfile.xrc
  4. If you use custom XRC elements, consider defining a schema for them too, it is simple to do.

Thursday, March 12, 2015

Attributing the contributions

One of the lesser, but still appreciable, benefits of switching to Git is that now we can properly record the author of the commit (e.g. the author of a patch), in addition to the (less important) person who committed it (e.g. me). While we tried to do this manually in the change log before, this couldn't be done for all the changes as the change log only mentions the most important ones and, sometimes, could be forgotten even for those changes for which it should have been done.

With Git, things are much more straightforward and you just need to provide your identity with your patch. The simplest way to do it is to use git format-patch command -- after ensuring that your name and email are correctly configured locally, of course. But you could also just mention them in your Trac ticket or wx-dev email and we'll use them when committing your changes (note for committers: you can always set GIT_AUTHOR_{NAME,EMAIL} for a particular commit to set the authorship information by hand).

Looking forward to your patches -- which will be now properly attributed to you instead of boosting my own commit stats!