This checks if `ccache` is available, and if so uses it.
The user can stil disable it via the ccache env variable, quoting:
disable (CCACHE_DISABLE) [boolean]
When true, ccache will just call the real compiler, bypassing the cache completely. The default is false.
At least Clang required `CCACHE_CPP2`.
The user does not have to set up anything, just to install ccache.
Of course, things like the cache's max size, its location and so on can
be configured.
References:
- https://ccache.samba.org/manual.html
By linking in the coordinate object file twice, we violate the ODR,
resulting in our program to not be "well-formed" in language lawyer
speak (hint: bad, very bad).
(How come no one noticed this all the time, this was introduced
somewhere between v4.5.0 and v4.6.0 from a quick look...)
References:
- C++14 standard (N3936.pfd): 3.2 One definition rule [basic.def.odr]
- http://eel.is/c++draft/basic.def.odr
Instead of including the `luabind.hpp` header that transitively includes
basically everything else, we now only include the appropriate header
for luabind's open function.
It is important that this function is declared in the header but the
definition comes from the luabind shared object (library), such that we
can detect linker errors, too.
By only including this header, we also no longer transitively include
the header for the `luaL_newstate` function, with we have to add
manually.
With these changes, detecting, compiling, linking and checking for
lua/luabind with cmake now works instantly, instead of the 3-4
seconds as it was before! Yay, progress!
We were stuck on the 4.5.0 tag from develop, since we searched for the
latest tag, but release tags are done on the master branch.
This commit rips out all the code for deriving the version on git tags.
Instead, we define major, minor, and patch versions in the CMakeLists
and then pass it on to:
- the `libosrm.pc` `pkg-config` file
- a `version.hpp` header that makes use of the preprocessor's string
concatenation to provide an easy way for generating version string
literals such as "v4.8.0".
That is, in the source code please now use the following defines:
#define OSRM_VERSION_MAJOR "@OSRM_VERSION_MAJOR@"
#define OSRM_VERSION_MINOR "@OSRM_VERSION_MINOR@"
#define OSRM_VERSION_PATCH "@OSRM_VERSION_PATCH@"
#define OSRM_VERSION "v" OSRM_VERSION_MAJOR "." OSRM_VERSION_MINOR "." OSRM_VERSION_PATCH
- remove profiling/coverage mix from debug build, as it is useless as of
now, re-enable this for a separate coverage build in the future
- use gcc's `-ggdb` and `-Og` flag (requires recent gcc) to provide
better debug information targeted for gdb and optimize what we can
- use `-fno-inline` and `-fno-omit-stack-pointer`, in order to be able
to jump around in gdb without functions being gone and keeping the
stack reference
This refines the last commit of parallelizing lto.
Discussion: this is ugly as hell, dispatching 1/ on the availability of
the `-flto` flag, then 2/ on the compiler since GCC allows `-flto=n`
whereas Clang for example does not.
I tried setting the CMake property `INTERPROCEDURAL_OPTIMIZATION`,
without any effect. All I could see was some lto related utilities in
the cmake debug output, but not in the actual compiler or linker
invocation.
This would eliminate the need for our hacks, with 1/ using an option
`WITH_LTO` setting `ON` by default, and based on this value setting the
`INTERPROCEDURAL_OPTIMIZATION` flag with CMake doing the actual work of
selecting the best LTO method on the target platform.
By the way, this also fixes a bug where we reset the `CMAKE_CXX_FLAGS`
to a variable that was never defined, resulting in setting the flags to
an empty string. Yay CMake, as usual.
References:
- http://www.cmake.org/cmake/help/v3.0/prop_tgt/INTERPROCEDURAL_OPTIMIZATION.html
GCC with link time optimizations does not to respect this mode
unfortunately, reuslting in warnings in release (default) build
mode from system includes such as boost, luabind and so on.
This remove the `-fPIC` flag, indicating position independant code
generation, from the build system.
Citing GCC's official code generation docs:
> This option makes a difference on the m68k, PowerPC and SPARC.
We do not support any of these architectures, so remove the flag!
References:
- https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
These are for standard compliance and should on by default:
-Wall -Wextra -pedantic
The problem is that even `-Wall` and `-Wextra` does not cover all
warnings, as to not break backward compatibility. Clang therefore
has the `-Weverything` flag, that really includes everything but is
overkill for the day to day development.
Thus, we in addition add:
-Wuninitialized -Wunreachable-code
to guard against undefined behavior from reading uninitialized variables
and warn for unreachable code.
With:
-Wstrict-overflow=1
the compiler warns us when it's doing optimizations based on the fact
that signed integer overflows are undefined behavior.
With:
-D_FORTIFY_SOURCE=2
we tell the compiler to replace functions like strcpy with strncpy where
it can do so, resulting in cheap and useful buffer overflow protection.
References:
- https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
- https://securityblog.redhat.com/2014/03/26/fortify-and-you/
- https://wiki.debian.org/Hardening
This rips out the Bost Spirit / Karma conversion code, using the stdlib
and lightweight alternatives instead.
The main benefit is an immense decrease in compilation times, for every
translation unit that requires the `util/cast.hpp` header.
Note: compared to the version before, there is a minor change in
behavior: the double `-0` was printed as `0` before and is now printed
as `-0`. This comes from the IEE754 standard, specifying signed zeros,
that is `+0` and `-0`. Interesting for us: JavaScript uses IEE754,
resulting in no breakage if used in arithmetic.
Small test case, left hand side was before, right hand side is now:
$ ./a.out
-1.123457 vs -1.123457
-1 vs -1
-1.3 vs -1.3
0 vs -0
0 vs 0
0 vs 0
1.3 vs 1.3
1.123457 vs 1.123457
References:
- https://en.wikipedia.org/wiki/Signed_zero
- http://www.boost.org/doc/libs/1_59_0/doc/html/boost/algorithm/trim_right_if.html
- http://www.boost.org/doc/libs/1_59_0/doc/html/boost/algorithm/is_any_of.html
With C++11 the stdlib gains:
- `std::stoi` function family to convert from `std::string` to integral type
- `std::to_string` to convert from number types to `std::string`
The only reason for hand-writing the conversion code therefore is
performance. I benchmarked an `osrm-extract` with the hand-written code
against one with the stdlib conversion features and could not find any
significant difference (we switch back and forth between C++ and Lua,
shaving off a few us in conversion doesn't gain us much).
Formatting arithmetic types in the default format with given precision
requires streams, but is doable in a few lines of idiomatic stdlib code.
For this, there is now the following function template available:
template <Arithmetic T, int Precision = 6>
inline std::string to_string_with_precision(const T);
that requires integral or floating point types and returns a formatted
string in the defaukt format with the given precision applied.
In addition this completely rips out Boost.Spirit from the `casts.hpp`
header, resulting in faster compile times.
Boom!
References:
- http://en.cppreference.com/w/cpp/string/basic_string/stol
- http://en.cppreference.com/w/cpp/string/basic_string/to_string
- http://www.kumobius.com/2013/08/c-string-to-int/
We needed this for Boost < 1.48, but per our Wiki on building OSRM:
> On Ubuntu 12.04 you will be limited to OSRM tag v0.3.10 because
> later versions **require Boost v1.49+** and installing this
> causes problems with libluabind-dev package.
Thus, rip it out!
To keep the commits atomic and isolated, I also refactored all call
sites that used the functionality from the portability fix.
While doing this, I also simplified the monster of around ~100 lines of
file path checking --- lambda's are awesome' use them!
References:
- http://stackoverflow.com/a/1750710
- https://github.com/Project-OSRM/osrm-backend/wiki/Building-on-Ubuntu
- removes `noexcept` specifier as we can not guarantee for not throwing
- uses a namespace instead of a struct + static function combination
- asserts for heading degree in [0, 360] range (both sides inclusive!)
- header only since implementation does not hide anything
- adds `inline` specifier as compiler hint
This reverts @6b2bf49 on the server components.
We do not want to parallelize there, as node should be used for
parallelizing the user requests onto multiple processes.
This switches out the `<variant/optional.hpp>` implementation of the
optional monad to the one from Boost.
The following trick makes sure we keep compile times down:
- use `<boost/optional/optional_fwd.hpp>` to forward declare the
optional type in header, then include the full blown optional header
only in the implementation file.
- do the same for the files we touch, e.g. forward declare osmium types,
allowing us to remove the osmium header dependency from our headers:
`namespace osmium { class Relation; }
and then include the appropriate osmium headers in the implementation
file only. We should do this globally...
References:
- http://www.boost.org/doc/libs/1_59_0/libs/optional/doc/html/index.html
- https://github.com/osmcode/libosmium/issues/123
This removes the custom `replaceAll` function, replacing it with
`std::replace` from the stdlib's `<algorithm>` header.
This also removes the respective unit test.
More importantly, this removes the dependency on the
`<boost/algorithm/string.hpp>` header in the `string_util.hpp` header.
The `static_rtree.hpp` header included `<booost/thread.hpp>` without using
anything from this header.
Removing it showed why:
the unit test for the rtree no longer built, since it was missing symbols
for Boost's `hash_combine`, used in the unit test.
Instead of relying on `<boost/thread.hpp>` including the proper header
for `hash_combine` by chance that we only use in the unit test, do the
following:
- remove `<boost/thread.hpp>` from the rtree implementation
- add `<boost/functional/hash.hpp>` to the rtree unit test
As always, include what you use.
