Welcome back.

In this short post, I continue my series about taking QuantLib to C++11. As you might recall, I’m trying to do it while staying with C++03 on the master branch. But how can we keep the two branches in sync?

Doing it manually, by merging from master as the latter evolves, is an effort that I’d try to avoid. I’d rather spend the little time I have on answering people on the QuantLib mailing list for a change.

Therefore, we need tooling—specifically, the integration of GitHub with Travis CI that I mentioned in the past. Besides running its checks at each new commit, Travis can also be configured to run a job daily (or weekly, or monthly) on a given branch. This seems to match our use case.

So, here’s what I did in the past few days. I started from the master branch, from which I had released QuantLib 1.13 recently. First, I merged into master the changes I wrote about in the last posts and that could also be applied on a C++03 code base: importing shared_ptr and friends into namespace ext, an opt-in switch between auto_ptr and unique_ptr, the removal of deprecated features, and a couple of other minor changes. These are the bottom six pull requests in the ongoing list for release 1.14. Finally, I created the C++11 branch from the resulting master so that they start from a common clean slate.

At this point, I applied enough modernization to be dangerous; that is, I used clang-tidy to apply the two automated changes that were more likely to cause conflicts. According to the table in my final post on automation, they were modernize-use-override and modernize-pass-by-value. Between them, they touched about 6000 lines in 1200 files, which quickly brought the branch to a point where we can have a meaningful experiment. (I’ll wait to apply the other changes until I see that the whole thing can work.)

Next, I set up Travis CI. It will check out the branch daily, try to merge it with master, and if that succeeds it will compile and run most of the tests (as described in the post I linked above). Here are the relevant parts of the configuration on the C++11 branch:

before_install:
  - docker pull ${DOCKER_IMAGE}
  - git fetch origin master:master
  - git merge --no-edit master || exit

script:
  - docker run ${DOCKER_IMAGE} ./autogen.sh
  - docker run ${DOCKER_IMAGE} ./configure --disable-static --enable-std-pointers --enable-std-unique-ptr CC="${CC}" CXX="${CXX}" CXXFLAGS="-O2 -std=c++11 -Wall -Werror"
  - docker run ${DOCKER_IMAGE} make -j 2
  - docker run ${DOCKER_IMAGE} ./test-suite/quantlib-test-suite --log_level=message -- --faster

The configuration is set for two parallel jobs, both running in a Docker image based on the latest Ubuntu release; one is using gcc and the other is using clang.

Finally, I started to merge pull requests on master and to see what happens. As I write this, I merged four of them, one of which caused a merge conflict in the daily Travis job which I had to fix manually. I already have another half dozen pull requests lined up for next release, and others will probably come in the next month or two.

As they are merged into master, Travis will try to merge them into the C++11 branch as well. I’ll keep track of whether it succeeds, and I’ll see if I can detect a trend after a while. If I’m forced to solve conflicts for every second or third PR I merge, maintaining a C++11 branch indefinitely might not be a tenable proposition; but if most pull requests go through cleanly, I might consider it.

I’ll be back here to report.

So far, I didn’t find the time (or, indeed, the motivation) to research, install and moderate a comment system. If you want to reach out with suggestions or questions, please send me a tweet or an email. I’ll report on your feedback in future posts.

Follow me on Twitter if you want to be notified of new posts, or add me to your Google+ circles, or subscribe via RSS or email: the buttons for that are in the footer. Also, make sure to check my Training page.