Moves Linux CI builds to the latest Ubuntu LTS.
- Bumps the GCC matrix to versions {7,8,9,10,11}, making 9 the default
for testing non-standard builds.
- Bump Node matrix to {12,14,16,LTS,latest} now that 10 is EOL.
- Fixes to CI builds due to library changes on newer distro.
A request to osrm-routed can be assigned to a thread which
is currently busy processing another request, even when there
are other threads/cores available. This unnecessarily delays
the response, and can make requests appear to hang when
awaiting CPU intensive requests to finish.
The issue looks like a bug in Boost.Asio multithreaded
networking stack.
osrm-routed server implementation is
heavily influenced by the HTTP server 3 example in the
Boost.Asio docs. By upgrading to Boost 1.70 and updating the
server connections to match the example provided in the 1.70
release, the problem is resolved.
The diff of the changes to the Boost.Asio stack are
vast, so it's difficult to identify the exact cause. However
the implementation change is to push the strand of execution
into the socket (and timer) objects, which suggests it could
fix the type of threading issue we are observing.
In newer versions of cmake, FindBoost uses Imported Targets for library
component variables, rather than file paths to the Boost libraries.
cmake uses these targets when linking (e.g. target_link_library) and
knows how to correctly substitute the values. However, the OSRM
pkg-config file that we generate doesn't do this, and ends up writing
the actual target symbols, hence the errors trying to link Boost::<component>.
To fix this for newer cmake versions, we create an intermediate configure step
that references the linker files for the imported targets. This is followed
by a generate step that performs the correct substitution.
See this thread for more details: https://cmake.org/pipermail/cmake/2018-December/068812.html
This is backwards compatible to the existing min cmake version (3.1).
However, building using cmake 3.1 fails with a package.json parsing error,
so this commit also bumps the min version to 3.2.
Replace Travis for continuous integration with Github Actions.
The Github Actions pipeline is functionally equivalent, with
all the same build permutations supported.
Whilst the Github Actions offering is broadly equivalent to
Travis, a few changes have been made as part of the migration.
- The 'core' and 'optional' Travis stages have been consolidated
into one build matrix. This is due to the current inability in
Github Actions to share build steps between jobs, so this avoids
having to duplicate the steps.
Optional stage jobs will now run in parallel with core jobs,
but they still remain optional in the sense that they don't fail
the build.
- A number of existing Github Action plugins are used to replace
functionality provided by Travis or other tools:
Node setup, caching, Codecov, publishing release artifacts.
- Linux builds are updated to build on Ubuntu 18.04.
MacOS builds are updated to run on 10.15. Similar to the
Travis Xenial upgrade attempt, some changes are required due
to underlying platform and compiler upgrades. This means some
Node 10 toolchains will no longer be supported.
Whilst there is opportunity to upgrade some dependencies and
make the CI steps more idiomatic, I've left this for future changes
and just focussed on functional replication.
The query if(WIN32 AND CMAKE_BUILD_TYPE MATCHES Debug) only works if you call CMake explicitly with the build configuration Debug. But if you generate Debug and Release all libraries are linked to the release version.
In the case of a shared object compilation, the resulting binaries need
that library. It was not installed along the others, leading to failures
when running osrm-extract.
Fixes#5603
Rename module partition to partitioner.
This cultivates naming used in existing modules like extractor,
customizer, etc. - noun vs verb (word partition is both though).
Unify CMAKE_CXX_COMPILER_ID tests without quoting/bracketing
the variable to use implicit expansion.
Replace STREQUAL with MATCHES to avoid policy warning about
attempt to expand "MSVC" variable, where it literal is intended.
- Adding sides parameter into base parameters, it can take the values SIDE, OPPOSITE or DEFAULT.
- Adding url parser for "sides" parameter, url values are "s" for SIDE, "o" for OPPOSITE and "d" for DEFAULT, example : "sides=s;s".
- Checking parameters, if "sides" parameter is used, the number of parameter is the same as number of location.
- Create a phantom to start at side driving or Opposite side driving.
Signed-off-by: FILLAU Jean-Maxime <jean-maxime.fillau@mapotempo.com>
* optionally include condition and via node coords in InputRestrictionContainer
* only write conditionals to disk, custom serialization for restrictions
* conditional turn lookup, reuse timezone validation from
extract-conditionals
* adapt updater to use coordinates/osm ids, remove internal to external map
* add utc time now parameter to contraction
* only compile timezone code where libshp is found, adapt test running
* slight refactor, more tests
* catch invalid via nodes in restriction parsing, set default cucumber
origin to guinée
* add another run to test mld routed paths
* cosmetic review changes
* Simplify Timezoner for windows build
* Split declaration and parsing parts for opening hours
* adjust conditional tests to run without shapefiles
* always include parse conditionals option
* Adjust travis timeout
* Added dummy TZ shapefile with test timezone polygons
* [skip ci] update changelog
Does not run the nodejs tests in sanitized builds. We'd have to
export LD_PRELOAD='/usr/lib/x86_64-linux-gnu/libasan.so.2'
the asan lib. But it seems like our Clang from mason does not like the
system's libasan. Also we'd need a suppression file for v8 and node.
Quick follow up for https://github.com/Project-OSRM/osrm-backend/pull/3570:
there is no reason not to build the `osrm-components` tool by defualt.
Backwards compatible. Users still specifying the option will see:
> Manually-specified variables were not used by the project:
> BUILD_COMPONENTS
