[omniorbpy] add port

[Neumann-A]

No description provided.

[MonicaLiu0311]

I'd like to confirm with you: does OmniORBpy neither export config files nor generate .pc files?

Edit: And I found that there are tools/ folders in the debug/ directory of omniorb and omniorbpy.

[Neumann-A]

Edit: And I found that there are tools/ folders in the debug/ directory of omniorb and omniorbpy.

Removed.

I'd like to confirm with you: does OmniORBpy neither export config files nor generate .pc files?

That is correct. Its a python module build ontop omniorb and required to run/build freecad.

[data-queue]

Is omniorbpy a C++ library or a python module?

[Neumann-A]

Is omniorbpy a C++ library or a python module?

It is a python module build on top of omniorb

[data-queue]

Is this module installed by other package managers, such as pip? Why would a C++ user consume this library from vcpkg instead of through a Python package manager?

[data-queue]

Did you generate this file? And why is it needed?

[Neumann-A]

Similar file to what is already in omniorb itself. It contains the rules for linking, compiler flags etc.

[Neumann-A]

Is this module installed by other package managers, such as pip? Why would a C++ user consume this library from vcpkg instead of through a Python package manager?

Because python is embedded in the c++ application. This requires everything to be consistently build/supplied.
Other question? Why should I use pip with all its little inconsistencies when I can use vcpkg for just everything and get everything in a consistent manner?

[BillyONeal]

Is this module installed by other package managers, such as pip? Why would a C++ user consume this library from vcpkg instead of through a Python package manager?

Because python is embedded in the c++ application. This requires everything to be consistently build/supplied.
Other question? Why should I use pip with all its little inconsistencies when I can use vcpkg for just everything and get everything in a consistent manner?

The issue is that the Python ecosystem has already had disservices done to it by people trying to repackage its bits in apt or similar. We don't want to be competing with pip by adding things substantially identical to things in pip, but worse because they don't compose across universes.

To proceed here we need to understand how to tell people why they should get this from us. "I don't want to also call pip for the Python parts" is not a very good reason. Particularly given that other package management systems in similar situations don't seem to have left people happy.

/cc @m-kuhn @Osyotr since you've been invested here

[m-kuhn]

An example why I want to have python packages managed by the same system that manages my native libs:

I have an application which uses the qgis port. This port depends among others on qt and gdal, offers python bindings and for this depends on sip and pyqt. These python packages link to native libs (qt). Installing them through pip will install conflicting libraries as part of the python wheel. The same situation applies to e.g. fiona with gdal.

[Neumann-A]

(removed vcruntime deps etc for better view.)

E:\all\vcpkg\installed\x64-win-llvm-opt-rel\tools\freecad-ondsel\bin>dumpbin FreeCAD.exe /DEPENDENTS
  Image has the following dependencies:
    FreeCADGui.dll
    FreeCADApp.dll
    FreeCADBase.dll
    fmt.dll
    Qt6Widgets.dll
    python311.dll
    Qt6Gui.dll
    Qt6Core.dll

Dump of file FreeCADGui.dll
  Image has the following dependencies:
    FreeCADApp.dll
    Coin4.dll
    Qt6PrintSupport.dll
    Qt6SvgWidgets.dll
    Qt6Network.dll
    Qt6UiTools.dll
    pyside6.cp311-win_amd64.dll <- Python module
    FreeCADBase.dll
    xerces-c_3_2.dll
    boost_filesystem-clangw16-mt-x64-1_83.dll
    fmt.dll
    Qt6Xml.dll
    Qt6Svg.dll
    Qt6OpenGLWidgets.dll
    Qt6Widgets.dll
    Qt6OpenGL.dll
    shiboken6.cp311-win_amd64.dll # <- Python module
    python311.dll
    Qt6Gui.dll
    Qt6Core.dll

Dump of file pyside6.cp311-win_amd64.dll
    shiboken6.cp311-win_amd64.dll
    python311.dll
    Qt6Core.dll

Dump of file FreeCADGui.pyd
    FreeCADGui.dll
    FreeCADApp.dll
    FreeCADBase.dll
    fmt.dll
    Coin4.dll
    Qt6Widgets.dll
    python311.dll
    Qt6Gui.dll
    Qt6Core.dll

Dump of file QtGui.cp311-win_amd64.pyd # PySide Python QtGui Module. 
    pyside6.cp311-win_amd64.dll
    shiboken6.cp311-win_amd64.dll
    python311.dll
    Qt6Gui.dll
    Qt6Core.dll

Dump of file MatGui.pyd # One of the FreeCAD workbenches
    Material.pyd
    FreeCADGui.dll
    FreeCADApp.dll
    FreeCADBase.dll
    fmt.dll
    Coin4.dll
    Qt6Svg.dll
    Qt6Widgets.dll
    python311.dll
    Qt6Gui.dll
    Qt6Core.dll

Obeservation:
a) Python version needs to be consistent between application and and python modules
b) Qt versions needs to be consistent between application and python modules due to possible interaction of widgets between application in c++ and the python modules.
c) Python is embedded in this case and python modules needs to be deployed with the application

[dg0yt]

pip doesn't use vcpkg asset caching.

[MonicaLiu0311]

Is there any new progress?