[OpenTURNS] add new port

[Neumann-A]

• 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 ... controlled by USE_ variables which are all ON.
• 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 docs/examples/adding-an-explicit-usage.md 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.

[github-actions]

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

All manifest files must be formatted

./vcpkg format-manifest ports/*/vcpkg.json

Diff

diff --git a/ports/openturns/vcpkg.json b/ports/openturns/vcpkg.json
index 328fc74..d243331 100644
--- a/ports/openturns/vcpkg.json
+++ b/ports/openturns/vcpkg.json
@@ -6,8 +6,8 @@
   "license": null,
   "dependencies": [
     "blas",
-    "boost-random",
     "boost-multiprecision",
+    "boost-random",
     "ceres",
     "cminpack",
     "dlib",

PRs must add only one version and must not modify any published versions

When making any changes to a library, the version or port-version in vcpkg.json or CONTROL must be modified.

error: checked-in files for openturns have changed but the version was not updated
version: 1.2.0
old SHA: 3b9c53996a09bfaf5f4292c0b42e820e7b5349d0
new SHA: 9f8dfa8549b68df28e313b8232800d689fd30411
Did you remember to update the version or port version?
Use --overwrite-version to bypass this check
***No files were updated***

[Neumann-A]

Ok static stuff seems to be just missing linking gmp

[BillyONeal]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Neumann-A]

@BillyONeal any hint how i should solve the osx configure error here? Seems like the bison version on the vm is too low. Only has 2.3 and 2.4 is required. This is one of the reasons why I think we need tool ports to deal with the versions of those in the same way as the rest.

[BillyONeal]

@BillyONeal any hint how i should solve the osx configure error here? Seems like the bison version on the vm is too low. Only has 2.3 and 2.4 is required.

I think a baseline skip is appropriate for that.

This is one of the reasons why I think we need tool ports to deal with the versions of those in the same way as the rest.

Tool ports come with their own problems though. For instance, they expose the tool to the installed tree which is generally undesirable for toolset parts. And they effectively never take things from the system even if those are perfectly good. (They make the VCPKG_FORCE_SYSTEM_BINARIES / we fail on arm linux or alpine etc. problem worse) I'm on the hook to have a cohesive answer for fetch/tool-ports/artifacts/find_acquire_program soon, will keep you posted.

[BillyONeal]

This LGTM as long as the usage makes sense to you, @Neumann-A , can you confirm?

Thanks for the new port!

[Neumann-A]

can you confirm?

I mean it is the same usage as the heuristics and it looked right to me considering what targets gets expored which is why i didn't bother to add a usagge.

[BillyONeal]

I've been adding them just to get rid of the heuristic part of the message and asking folks who are adding ports to confirm that's what they expect. (When a new port is added hopefully the person adding knows what they wanted to do with it?)

[dg0yt]

When a new port is added hopefully the person adding knows what they wanted to do with it?

This may be to optimistic. People may have their own find procedures or do not use CMake at all. And even our reviewers didn't object against obviously false results (find_package(cmake REQUIURED)). However, my changes seem to have eliminated a big share of the bad output, in related to subdirectories and find modules.

[Neumann-A]

I just need the port to fix the vtk all feature. As far as I can tell usage there is via variables and not targets.

[Neumann-A]

@MonicaLiu0311 please remove the tag author-response (at least I don't know what to response to here.)

[MonicaLiu0311]

• The generated "usage text" is accurate.

openturns provides CMake targets:

    # this is heuristically generated, and may not be correct
    find_package(OpenTURNS CONFIG REQUIRED)
    target_link_libraries(main PRIVATE OT)

The usage test passed(The header files can be found.).