Linux Deployment

[pthom]

This discussion was opened following this reddit discussion (see messages exchanged with metux-its),
and will serve as a place for discussion about this.

The objectives of this discussion are: how can Hello ImGui be ready so that an app developed with it may be included as part of a linux distro.

Points that were raised by metux-its:

1. "link third parties library dynamically"
   A commit was pushed about this topic. Under linux, third parties (i.e. Gflfw and/or SDL) now use system wide libraries.

2. "Deploying anything outside the Distro's package management is a bad idea"
   Actually, at this moment, HelloImGui does not deal with the deployment under Linux
   At the moment, deploying an app under Linux requires

• copying the exe
• copying the assets folder
• ensuring libglfw3-dev is installed (or libSDL)
  It is up to the app developper to handle this installation via a package manager, CPack or anything else.

3. bundling own copies of 3rdparty packages:

• Under Linux, HelloImGui uses Glfw and/or SDL (from system libraries)
• It also includes the official repo of ImGui , on the docking branch, as a submodule. It is linked statically, as per the recommendations on the official repo. TLDR: ImGui does not guarantee backward nor forward ABI compatibility, and releases are emitted every month. It is also a quite small, once compiled.

---

Note about ImGui Bundle: ImGui Bundle is built on top of HelloImGui and does include some more 3rd party packages (small widgets libraries built on top of ImGui).
Some are based on fork from the original version, because a support for Python bindings was added, as well as patches for HighDPI support. PR were posted to these repos when possible. Another similar discussion about this repo can also be opened.

[metux]

1. "link third parties library dynamically"
   A commit was pushed about this topic. Under linux, third parties (i.e. Gflfw and/or SDL) now use system wide libraries.

Great :)

For the protocol:

In general, applications should always use distro-provided libraries, because distros maintain them (security, bugfixes, ...), and users receive important updates very fast and automatically. When libs are bundled, this doesn't work, and we end up w/ lots of duplicated work. Another aspect is, there may be reasons for the distros to change something in those 3rdparty libs, so it fits better into the ecosystem - that also won't work w/ bundling. And there's also risk of various kinds of library(-version) clashes.

2. "Deploying anything outside the Distro's package management is a bad idea"
   Actually, at this moment, HelloImGui does not deal with the deployment under Linux
   At the moment, deploying an app under Linux requires

• copying the exe
• copying the assets folder

The package's build system (cmake files) should install all files exactly as they'll have to be in the final system
(note that it's important to honor the filesystem hierarchy standard), but under a prefix given by the caller - the standard way is via DESTDIR variable. So, eg., the executable would land under $(DESTDIR)/bin, ...

From here, the higher order build systems (distro's package build machinery) can pick it up.

• ensuring libglfw3-dev is installed (or libSDL)

Does the dev-package really need to be installed at runtime ?

3. bundling own copies of 3rdparty packages:

• Under Linux, HelloImGui uses Glfw and/or SDL (from system libraries)

Great :)

• It also includes the official repo of ImGui , on the docking branch, as a submodule. It is linked statically, as per the recommendations on the official repo. TLDR: ImGui does not guarantee backward nor forward ABI compatibility, and releases are emitted every month. It is also a quite small, once compiled.

Okay, valid exception case. We should - from distro perspective - consider this not a traditional library.
Maybe as just a pure -dev package, similar to the "header only libs", or golang modules.