oxfordrse / template-project-cpp Goto Github PK

Both the clang and gcc travis builds have the following snippet in the output:

Setting environment variables from .travis.yml
$ export CXX=g++-5
$ export BUILD_TYPE=Debug
$ export CXX=g++
$ export CC=gcc
$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

Setting environment variables from .travis.yml
$ export CXX=clang++-5.0
$ export BUILD_TYPE=Debug
$ export CXX=g++
$ export CC=gcc
$ g++ --version
g++ (Ubuntu 4.8.5-4ubuntu8~14.04.2) 4.8.5

So we appear to be ending up with the same (old) gcc version, and I think this might be causing the spurious warnings we're getting related to #9.

See #16, #17.

Let's have one branch containing additional libraries that we keep up-to-date with master, and keep as the minimal and simple template project.

Name for the branch @martinjrobins?

How about extra_libs?

The template project still needs plenty of documentation to explain what each bit is doing:

• CMakeLists.txt
• MyLibrary.{cpp,hpp}
• MyTests.cpp
• travis.yml
• appveyor.yml
• codecov
• clang-format
• clang-tidy

This seems to be the current best practice for detecting memory errors in C++ code, and it seems very straightforward to use.

AddressSanitizer is a fast memory error detector. It consists of a compiler instrumentation module and a run-time library. The tool can detect the following types of bugs:

Out-of-bounds accesses to heap, stack and globals
Use-after-free
Use-after-return (runtime flag ASAN_OPTIONS=detect_stack_use_after_return=1)
Use-after-scope (clang flag -fsanitize-address-use-after-scope)
Double-free, invalid free
Memory leaks (experimental)
Typical slowdown introduced by AddressSanitizer is 2x.

@martinjrobins what's the modern-CMake-approved method of passing

-O1 -g -fsanitize=address -fno-omit-frame-pointer

to the (clang) compiler, and

-g -fsanitize=address

to the (clang) linker?

tried to turn on leaksanitizer on travis clang setup, but got this error:

$ ctest -j2 --output-on-failure
Test project /home/travis/build/OxfordRSE/template-project-cpp
    Start 1: test1
1/1 Test #1: test1 ............................***Failed    0.01 sec
===============================================================================
All tests passed (6 assertions in 2 test cases)
==3894==LeakSanitizer has encountered a fatal error.
==3894==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==3894==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

https://codecov.io/gh/OxfordRSE/template-project-cpp

Some source files have copyright information that seems to differ from the license file - do these need updating?

Tried xcode 9.1, 9.2 & 9.3, but the cmake FindOpenMP fails for all of them

At the moment we are using .h for headers and .cpp for implementations.

Catch is currently .hpp. I think it would be useful to have complete consistency within the project. My vote would be for changing all headers to .hpp (something about the filenames being the same length...), although I'm not strongly wedded to one or the other.

Your thoughts @martinjrobins?

I've not used Codecov before, so probably one for @martinjrobins:

This output looks as though codecov is checking a whole bunch of files including

File '/usr/include/boost/exception/exception.hpp'
File '/usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp'
File '/usr/include/c++/5/bits/postypes.h'

Can we get it to analyse only our project files?

@martinjrobins what do you think about adding in something from Eigen?

Another very short function that, perhaps, accepts an Eigen matrix and returns the largest (in magnitude) eigenvalue? Or some other trivial wrapping of some existing Eigen functionality, just to provide a minimal example?

@martinjrobins what are your thoughts on Abseil support?

Would be different than other libraries such as Eigen and Boost they strongly recommend building it from your project tree.

We could add it as a submodule, and then simply

add_subdirectory(abseil-cpp)

and the abseil internals sort everything else out nicely.

I would be in favour of adding it. Besides a number of really cool features and utilities, it pre-supports a number of newer C++ features which is good from a "best practices" point of view.

The downside is that having a submodule is a little annoying in terms of keeping the project as simple as possible, and does (marginally) increase the compile time of the project, so would be happy to leave it out if you're not keen.

travis says (for both gcc and clang):

/home/travis/build/OxfordRSE/template-project-cpp/src/MyLibrary.cpp:44:11: warning: thrown exception type is not nothrow copy constructible [cert-err60-cpp]
    throw std::out_of_range("non-negative argument required");

This doesn't seem like a valid warning, since we are just using a standard library exception! Not sure how to fix this

This is currently still linking to Jason Turner's repo.

Travis thinks it's running a build with gcc and clang, but because the script specifies CXX and CC I'm fairly sure it's doing the same identical build each time.

Can we get it actually building with both compilers?

See #8 for discussion about CMake consistency for the coverage option.

How about:

# Setup coverage testing for GCC or Clang
option(Template_ENABLE_COVERAGE "Enable coverage reporting for GCC or Clang" FALSE)
if (Template_ENABLE_COVERAGE)
    if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU" OR ${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
        target_compile_options(mylib PUBLIC --coverage -O0)
        target_link_libraries(mylib PUBLIC --coverage)
    else()
        message(FATAL_ERROR "GCC or Clang required with Template_ENABLE_COVERAGE: found ${CMAKE_CXX_COMPILER_ID}")
    endif()
endif()

Is this what you had in mind, and would this mess up the Travis integration?

For starters let me just say that this is a great template to start any C++ project with a very good foundation.

I would just like to make a suggestion, based on the only thing I had to add to this template, and maybe hear you thoughts on it.

What do you think about including a generic dockerfile with ubuntu or alpine with both the build tools and boost?

Jason Turner has a cpp_starter_project that's intended to have best practises for CMake, with travis, appveyor etc integrations.

Might save a bit of time to use some of this as a basis?

From @martinjrobins original post.

Libraries:

• Boost
• OpenMP (this is linked, but I still want to setup a test that uses openmp)

Dependencies:

• CMake
• Catch2

Integrations:

• travis-ci (with linux and mac)
• codecov
• appveyor

A few other suggestions:

• clang-format
• clang-tidy (put in a config file, but need to actually use it)