Discrepancy between Catch|single-include and Catch|multi-include

[Martin Moene]

The single-include file of Catch `single_include/catch.hpp` isn't always in-step with the include files that comprise Catch.

This can lead to confusion on the part of a user.

The discrepancy is most easily seen by comparing the date in the header of `catch.hpp` with the date of the last commit. The date in the header is set by the script `scripts/generateSingleHeader.py` if and when it is run [1].

Can 'we' do better? How?

[1] The script `scripts/generateSingleHeader.py` takes an optional argument `nobump` that can be used to update the single include file without changing its build number.

[Fraser Hutchison]

Maybe a pre-commit hook invoking generateSingleHeader.py nobump would help?  It could even add the updated single header to the commit, but that might be taking it a step too far.

It looks like the python script replaces the generated timestamp even when passed the "nobump" arg.  It might be better to leave that unaltered if we're looking at auto-running the script?

[Phil Nash]

The idea has always been that the script could be run as a post-build step on the build server (after all the testing). There is an instance of TeamCity running on a Windows VM that is monitoring GitHub and CI-ing Catch.

The reasons this hasn't been done yet are threefold:

1. Time: In particular because this requires a decent stable connection to maintain remote access to the build server to get it set up. Since I do most of my work on the train this is difficult (although I should be able to do some of it on a local mirror).

2. I'd only want to automatically submit an updated and bumped single header if I'm sure that all the tests pass - ideally for all platforms (or at least all platforms I'm explicitly targeting). TeamCity has the ability to have build agents running on different platforms, so in addition to the Windows build I'd like to see it running on Linux and OS X VMs too. Currently the build server is not yet running the approval test scripts, too - so that would need to be setup.

3. I'm still not 100% sure I want it fully automated. I think it's worth it - but it is quite nice to be able to manually express it as a type of "release". In practice, though, I've often put out buggy "releases", or not updated it when it should have been - so automating should bring more benefit than disadvantage.

Which brings me back to the time issue. So if anyone would like to help out with that side of things I'd be really grateful! :-)

BTW the timestamp update is very deliberate. If I regenerate due to something very minor - usually within a small time window from a previous update (typically because, just as I'm pushing the change I realise I missed something), then I don't want to pollute the build number scheme, but I do want to uniquely identify it. I think this would be even more important with an automated script. Furthermore I believe it should bump the build number too.

[Wichert Akkerman]

On 08 Nov 2013, at 09:11, Phil Nash <pan.e...@gmail.com> wrote:

> The idea has always been that the script could be run as a post-build step on the build server (after all the testing). There is an instance of TeamCity running on a Windows VM that is monitoring GitHub and CI-ing Catch.
>
> The reasons this hasn't been done yet are threefold:
>
> 1. Time: In particular because this requires a decent stable connection to maintain remote access to the build server to get it set up. Since I do most of my work on the train this is difficult (although I should be able to do some of it on a local mirror).
>
> 2. I'd only want to automatically submit an updated and bumped single header if I'm sure that all the tests pass - ideally for all platforms (or at least all platforms I'm explicitly targeting). TeamCity has the ability to have build agents running on different platforms, so in addition to the Windows build I'd like to see it running on Linux and OS X VMs too. Currently the build server is not yet running the approval test scripts, too - so that would need to be setup.
>
> 3. I'm still not 100% sure I want it fully automated. I think it's worth it - but it is quite nice to be able to manually express it as a type of "release". In practice, though, I've often put out buggy "releases", or not updated it when it should have been - so automating should bring more benefit than disadvantage.
>
> Which brings me back to the time issue. So if anyone would like to help out with that side of things I'd be really grateful! :-)

I have a jenkins running; it should be pretty easy to have that run the tests, create a single include file and upload that somewhere if the tests are passing.

[Fraser Hutchison]

On Friday, November 8, 2013 8:11:45 AM UTC, Phil Nash wrote:

The idea has always been that the script could be run as a post-build step on the build server (after all the testing).

Wouldn't it be safer to have the single header be part of the test suite?  So create it pre-build, then run the tests.
 

There is an instance of TeamCity running on a Windows VM that is monitoring GitHub and CI-ing Catch.

The reasons this hasn't been done yet are threefold:

1. Time: In particular because this requires a decent stable connection to maintain remote access to the build server to get it set up. Since I do most of my work on the train this is difficult

Your day job's not Train Driver I hope? :-)
 

(although I should be able to do some of it on a local mirror).

2. I'd only want to automatically submit an updated and bumped single header if I'm sure that all the tests pass - ideally for all platforms (or at least all platforms I'm explicitly targeting). TeamCity has the ability to have build agents running on different platforms, so in addition to the Windows build I'd like to see it running on Linux and OS X VMs too. Currently the build server is not yet running the approval test scripts, too - so that would need to be setup.

3. I'm still not 100% sure I want it fully automated. I think it's worth it - but it is quite nice to be able to manually express it as a type of "release". In practice, though, I've often put out buggy "releases", or not updated it when it should have been - so automating should bring more benefit than disadvantage.

Well, I guess that's why I quite like the pre-commit hook option.  It's automatic in that it always invokes the script, but it's up to the committer whether to include the updated single header in the commit or not.  However, I imagine a server-side hook would indeed be best if you want it fully automated.
 

Which brings me back to the time issue. So if anyone would like to help out with that side of things I'd be really grateful! :-)

BTW the timestamp update is very deliberate. If I regenerate due to something very minor - usually within a small time window from a previous update (typically because, just as I'm pushing the change I realise I missed something), then I don't want to pollute the build number scheme, but I do want to uniquely identify it. I think this would be even more important with an automated script. Furthermore I believe it should bump the build number too.

I agree where the contents of the single header have changed, particularly about the build number.  However, at the moment the script will regenerate a new version even if the single header hasn't changed.  Would you want the version and/or timestamp updated even if just a test file or markdown file were changed?