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!
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.
Setup
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
http://www.wxwidgets.org/wxxrc.
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
validator.nu (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
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. http://www.wxwidgets.org/wxxrc
but currently this doesn't work, seemingly because of a bug in Jing handling
HTTP-to-HTTPS redirections. The following command does work:
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
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 file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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!
