[vcpkg baseline][omplapp] Skip due to conflict with ompl

[WangWeiLin-MV]

Fix https://dev.azure.com/vcpkg/public/_build/results?buildId=105429&view=logs&j=ac0731cb-f2f9-5764-2e0a-a6fa8ebb4a08

error: The following files are already installed in /Users/vcpkg/Data/installed/arm64-osx and are in conflict with omplapp:arm64-osx
Installed by ompl:arm64-osx  
debug/lib/libompl.dylib
    lib/libompl.dylib

Since omplapp coupled with ompl, and ompl has been fixed and enabled CI test in #40080:

• Mark omplapp as skip
• Remove command of "delete conflicts ompl files".

Checklist

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

Test

The port installation tests pass with the following triplets:

• x64-linux

[dg0yt]

How do you ensure that the vendored ompl runtime libs created and used during the build of omplapp are compatible with the runtime libs installed by ompl?

[WangWeiLin-MV]

How do you ensure that the vendored ompl runtime libs created and used during the build of omplapp are compatible with the runtime libs installed by ompl?

Thanks for your comment, the build-in ompl version is not the same as ompl.

---

Given that omplapp is highly coupled to its built-in ompl, and based on the history of current port (#18908), temporarily disable it in ci.baseline.txt, which also allows for conflicting files to not need to be deleted.

[BillyONeal]

According to https://ompl.kavrakilab.org/download.html "The OMPL.app repository contains the OMPL repository as a submodule.". I checked, and omplapp's submodule for 1.6 references the same SHA as for ompl 1.6, and they were released on the same day.

Does it make sense to remove omplapp and add ompl[app] which locks the inner ompl sources at the same value?

[WangWeiLin-MV]

According to https://ompl.kavrakilab.org/download.html "The OMPL.app repository contains the OMPL repository as a submodule.". I checked, and omplapp's submodule for 1.6 references the same SHA as for ompl 1.6, and they were released on the same day.

Does it make sense to remove omplapp and add ompl[app] which locks the inner ompl sources at the same value?

omplapp does not directly use the artifact of ompl, but bypasses ompl/CMakeLists.txt to compile its components like this omplapp/CMakeLists.txt#L252-L257:

add_subdirectory(ompl/doc)
add_subdirectory(ompl/src)
add_subdirectory(ompl/py-bindings)
add_subdirectory(ompl/tests)
add_subdirectory(ompl/demos)
add_subdirectory(ompl/scripts)

And there are many different parts between the two files omplapp/CMakeLists.txt and ompl/CMakeLists.txt.

Splitting the two projects seems need a lot of changes, I will discuss with upstream.

[talregev]

I will discuss with upstream.

Can you post the link to the discussion?

[WangWeiLin-MV]

@talregev Sorry for late, I submitted the issue now.

[talregev]

@WangWeiLin-MV Don't worry about it.
Thank you for sharing the link.

[WangWeiLin-MV]

Close before upstream update.