[or-tools] adds or-tools as new port

[JulZimmermann]

Adds Google or-tools lib as a port.

• highs solver is useable as an optional feature
• coin-or solver couldn't be added because of [coin-or-cbc] pre-release-version is used #39342. Once this is issue is resolved coin-or can also be added as an optional feature

---

• Changes comply with the maintainer guide.
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

[BillyONeal]

Are there library components here or is this entirely providing a tool? We generally don't put tooling in our registry unless there is some kind of interdependency with the exact tool and some other library component, because we believe binary distribution systems like nuget or apt or dnf are a better fit for those situations. For example, protoc must match the libprotobuf you get exactly for the resulting generated bits to be link compatible, so we will distribute that.

I'm marking this PR as a draft because several builds are failing, please either fix the supports expression to describe what the port actually supports and mark 'ready for review' afterwards.

[JulZimmermann]

This is a library for solving optimization problems. The executables build also (the tools) are not really needed. Your right. I'll try to disable the build of them.

I'll also have a look at the supported platforms

[Mengna-Li]

@JulZimmermann I encountered the following error while testing the usage:

CMake Error at CMakeProject2/CMakeLists.txt:14 (target_link_libraries):
1> [CMake]   Error evaluating generator expression:
1> [CMake] 
1> [CMake]     $<TARGET_OBJECTS:ortools_math_opt_core>
1> [CMake] 
1> [CMake]   Objects of target "ortools_math_opt_core" referenced but no such target
1> [CMake]   exists.

[JulZimmermann]

@Mengna-Li I disabled the build of the math_opt targets. Now only the really needed ortools target is build.

[JulZimmermann]

Unfortunately, there still seems to be a problem.
To use BUILD_MATH_OPT=OFF I also had to set USE_GUROBI=OFFwhich makes sense since gurobi is a proprietary third-party solver.

However, with these settings I have linker errors on linux now. Looks like a bug in the cmake. I'll need to investigate this further.

[dg0yt]

On b135bb7: Is this expected to pick system libraries if available?
(Reusing the cached artifact will not install system libraries...)

[JulZimmermann]

@Mengna-Li It seems USE_GUROBI=OFF isn't supported (See: https://github.com/google/or-tools/blob/8edc858e5cbe8902801d846899dc0de9be748b2c/CMakeLists.txt#L256C1-L256C73)
Therefore BUILD_MATH_OPT=OFF is also not supported and need to be build.

However, I added a using file describing that only the ortools::ortools CMake Target should be used

[JulZimmermann]

@dg0yt No, system libs shouldn't be used. Did I make a mistake in the port file so they are picked?

[dg0yt]

It seems USE_GUROBI=OFF isn't supported

Why shouldn't it be supported to turn it off? That CMake line doesn't enforce it, but adds preqrequisites.
This is one of the "system libs":

[JulZimmermann]

@dg0yt I'm not sure why the flag exists if it can't be used. That was confusing me too.
If you compile the lib with USE_GUROBI=OFF you get linker errors when trying to use the lib.

Fromor-tools CMakeListst.txt:

## GUROBI
# Since it is dynamicaly loaded upon use, OFF is currently not supported.
CMAKE_DEPENDENT_OPTION(USE_GUROBI "Use the Gurobi solver" ON "BUILD_CXX" OFF)
message(STATUS "Gurobi support: ${USE_GUROBI}")

In my opinion these options shouldn't exist if they can't be used.

However, because the gurobi lib would be "dynamicaly loaded upon use" there is no hard dependency on gurobi even when USE_GUROBI=OFF is not set

[dg0yt]

If you compile the lib with USE_GUROBI=OFF you get linker errors when trying to use the lib.

Upstream bug IMO.

However, because the gurobi lib would be "dynamicaly loaded upon use" there is no hard dependency on gurobi even when USE_GUROBI=OFF is not set

I see...

[Mengna-Li]

It seems that your format has been restored to its original state.

[Mengna-Li]

Note: I will be converting your PR to draft status. When you're ready, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.