andystanton / glfw-skeleton Goto Github PK

Build a Dockerfile that builds and runs the unit tests.
The base image Ubuntu 14.04 should be used as this supports gcc 4.9 through the test toolchain.

This task will be complete when:

• A Dockerfile exists
• The Dockerfile is based on Ubuntu 14.04
• The Dockerfile installs gcc 4.9
• The Dockerfile clones the glfw skeleton source
• The Dockerfile builds the glfw skeleton source
• The Dockerfile tests the glfw skeleton source
• A success code is returned if the tests have passed
• A failure code is returned if the tests have failed

I use Travis CI to do automated builds on github commits of glfw skeleton. Travis uses Ubuntu 12.04 which supports up to gcc 4.8. Some of the C++11 regex features are only supported from gcc 4.9.

I tried building gcc 4.9 from source in the travis pre install steps but this involves a +100 MB download which is slow and excessive, and therefore not good for CI. Another service, drone.io offers a service similar to Travis, and unfortunately the only available version of gcc is 4.8.

Instead I want to investigate setting up a CI server myself that is capable of running Docker, so that I have a guaranteed way of using all C++11 features.

Links:

• http://technosophos.com/2014/06/03/using-drone-and-docker-for-continuous-integration.html
• http://jipiboily.com/2014/from-zero-to-fully-working-ci-server-in-less-than-10-minutes-with-drone-docker
• https://registry.hub.docker.com/_/jenkins/
• https://registry.hub.docker.com/u/notyy/thoughtworks_go_server/
• https://registry.hub.docker.com/u/lvcodesmith/thoughtworks-go/

It should not be.

The application's logging outputs in colour using ansi escape code. This should be optional via a toggle so that it outputs correctly in terminals that do not support ansi colour e.g. CLion IDE, Windows command prompt.

This task will be complete when:

• The logging can be output using ansi colour.
• The logging can be output without using ansi colour.

The glfw library generates a configuration header based on the OS that cmake was invoked from. This header file is not deleted, so in the event the cmake'd sources are copied to another OS, some settings specific to the previous OS may be maintained despite the rake clean task.

Either the above process is bad or git clean should be invoked to clean each source root as follows:

git clean -dff
git clean -dffX

The first cleans everything except the contents of .gitignore. The second cleans only the contents of .gitignore.

catch std::regex_exception when doing regex_replace.

Currently the eyes are black squares. Instead draw white rectangles around the voids so that the background colour shows through instead of black.

There is currently no logging beyond using cout.

I had a look before for c++ libraries similar to log4j but there weren't any recently maintained ones. I think I'll write a simple one for now to prevent messing around with cout.

This task will be complete when:

• A logger class exists.
• A logger factory class exists that manages instances of Loggers.
• All existing standard out logging are switched to make use of the new class.

The application should accept command line options.

• A CLI class should parse the input supplied to the application.
• The CLI should include no-colour=true|false for toggling #17.

• Add more parameters to drawSkull method - colour and scale
• Add a colour helper
• Remove Adder/Multiplier headers
• Change tabs to spaces in .gitmodules

The configuration should be encapsulated in a class.

This task is complete when:

• There is a storage mechanism for the config.
• The CLI options are read into the config.
• The configuration can be read as a string.
• The configuration can be read as a boolean.
• The configuration can be read as an integer.

If the tests fail when run using the rake test goal, the rake command still succeeds. This is bad because CI builds depend on a bad exit code from rake to determine whether or not the build succeeded.

----------------------------------------------------------
Test Failed.
"glfw-skeleton-unittests" end time: Sep 21 20:38 UTC
"glfw-skeleton-unittests" time elapsed: 00:00:00
----------------------------------------------------------
End testing: Sep 21 20:38 UTC
The command "rake all" exited with 0.

As warnings are errors, the use of an OSX deprecated API call in GLFW causes the build to fail on Mavericks+

A user of this project should be able to extend it and then easily distribute it. The project builds an executable and copies shaders to the build output path. This means that sharing the application involves multiple files and does not automatically end up in the standard OS location for programs.

macOS has the concept of app bundles that are a folder that contains the executable and resources, and is treated as an executable itself. CMake allows the creation of app bundles as well as the ability to create a dmg image for distribution. There is a fixed folder structure required by app bundles, so some changes are likely to be required in the code that loads resources.

Windows does not have an equivalent to the macOS app bundle and applications are typically installed in their own folder in Program Files. CMake has the ability to create NSIS installers which can be used for distribution.

I don't know what the standard way to distribute Linux GUI apps is.

This outcome of this issue is to confirm what the distributable formats should be, and then implement it. Ideally this will be through mechanisms provided by CMake.

http://www.cmake.org/Wiki/CMake:Packaging_With_CPack#Using_CPack_with_CMake

From wikipedia:

CPack is a packaging system for software distributions which is tightly integrated with CMake, but can function without it.

It allows you to generate:

* Linux RPM, deb and gzip distributions of both binaries and source code.
* NSIS files (for Microsoft Windows)
* Mac OS X packages

This could be useful for packaging accompanying files e.g. shaders, readme

I was reading about pragma once and decided it would be a better fit for my code than the include guard macros that I currently have in all the headers.

This task will be complete when:

• All header files use #pragma once instead of include guards.

When building, as bandit (and by association, snowhouse) are included as cmake subdirectories, they are built and their tests run. While this may be desirable for debugging why tests aren't working, it's not necessary most of the time.

I submitted some PRs to bandit and snowhouse to allow their tests to be disabled which have now been merged. They can be used with the current master branch of snowhouse (ffa30f3961cea3d2d22cac245eab6003e546e4e8) so this task will update the version of snowhouse to that revision.