Heads up, upcoming incompatibility in the CP/Routing library

Hello all,

I will soon push a large incompatible change in the CP and Routing libraries.

The change will replace parameters (CP solver parameters, routing model parameters, routing search parameters) from struct to protobuf. This will also hide the C++ command line flags (cp_trace_search, routing_first_solution, ...) and make them redundant for controlling the behavior of the libraries. They are currently kept in the C++ library, but will be dropped out eventually.

With this move, all functionalities offered by the C++ command line flags will be available from all languages (provided you implement the command line parsing part).

Let's see an example (tsp)

Before (in C++):
   // Setting first solution heuristic (cheapest addition).
   FLAGS_routing_first_solution = "PathCheapestArc";
   const Assignment* solution = routing.Solve();

After (in C++, using the command line flags compatibility) :
   RoutingSearchParameters parameters = BuildSearchParametersFromFlags();
   const Assignment* solution = routing.SolveWithParameters(parameters);

After (in C++, using the recommended API):

   RoutingSearchParameters parameters = RoutingModel::DefaultModelParameters();
   const Assignment* solution = routing.SolveWithParameters(parameters);

In python:
    search_parameters = pywrapcp.RoutingModel.DefaultSearchParameters()
    # Setting first solution heuristic (cheapest addition).
    search_parameters.first_solution_strategy = (

In Java:
    RoutingSearchParameters search_parameters =

In C#:
    RoutingSearchParameters search_parameters =
    // Setting first solution heuristic (cheapest addition).
    search_parameters.FirstSolutionStrategy =

The relevant protobuf definitions are:
  • src/constraint_solver/solver_parameters.proto
  • src/constraint_solver/routing_parameters.proto
  • src/constraint_solver/routing_enums.proto
I also recommend reading the introduction to protocol buffers:

and the main site:

More details:

We use protobuf 3 as this is the only one supported by C#.

Proto3 do not have default values, as opposed to proto2.
Thus, for any parameter structure, there is a DefaultParameter() method (names varies) to actually create the parameter structure with the correct default values.

Python targets already pull protobuf from pypi.

I will add protobuf.jar to the java archive. Please add them to the class path if need be.

I will also add Google.Protobuf.dll to the .NET archive. The nuget will list Google.Protobuf as a dependency. Please note that this is a currently a pre-release (3.0.0 beta 2).

If you build from source, please re-run make third_party. It should build the missing pieces.

In the unlikely event you are using mono to compile C# code. I have changed the installation process for mono. or-tools will no longer compile mono. To generate .NET code, it must find mcs on system path. And it requires at least mono (it refuses to compile protobuf with earlier versions).

So, to use mono on Mac OS X, I recommend downloading the universal installer. It should add the mono64 and mcs binaries on the path. On linux, I recommend downloading the sources, compiling them, and adding the <mono_install_dir>/bin to your path.

Once or-tools detects the presence of mono on unix machines, then the csharp and test_csharp targets become effective.

Please note that the installation of mono must be done before make third_party, in order to compile the Google.Protobuf dll.


Popular posts from this blog

Linking glpk with or-tools on unix

Changing the way we link with SCIP