kickui dependencies

[windelbouwman]

The kickui looks pretty neat! I ran into some hurdles during building. I had to install imgui and I manually copied the portable file dialogs library. I would suggest to include both imgui and portable file dialogs are source libraries directly in git. This make building the kickui a smoother experience when not using vcpkg/conan.

My proposal would be to store both imgui and portable-file-dialogs into the tools/common folder under a potentially third party libraries subfolder. What do you think?

[trns1997]

I personally would avoid vendoring third-party libraries directly into the repo. Bundling dependencies comes with a real maintenance burden, keeping them up to date, tracking upstream changes, and managing patches over time adds up quickly. That's exactly why we've delegated dependency management to Conan and scripted the setup up to make usage as easy as possible.

I would recommend going the Conan route for the smoothest build experience. If the setup feels rough then we can look into ways to improve the UX.

I would be curious to what @leducp thinks?

[windelbouwman]

Some other thoughts on this topic.

packaging
If at some point there is an aim to allow kickcat to be packaged on archlinux, debian, etc, it is beneficial to have a CMake buildable package. It becomes harder for package creators to package software that downloads dependencies during building. Also think of yocto here, having a CMake only package makes it easier to create bitbake recipes for KickCAT.

conventions
It looks to me that libraries such as imgui and portable file dialog are by design intended to be included in a vendor folder. For example imgui does not have a CMakeLists.txt file, because the reasoning is that the code is vendored. It might be good to follow this flow and intention of the imgui authors.

So far my arguments on why I think vendoring might be a good plan 👍

[leducp]

Im not sure that vendoring some librairies and not others are a good approach.
Maybe we can have a help script to smooth this specific use case?
What about relying on the distribution package for instance ?
In case of yocto/debian/fedora or any distribution, it is quite common to reuse what they are already providing and the current build system should be able to use them (it is a find package at the end)