Should the vendor/ directory of the C++ client be optional?

General Discussions
1

Currently, there is a vendor/ directory in the mender C++ client source code, and building them is required.

However, it may be best to make those dependencies optional, as both Buildroot and Yocto provide their own

expected:

  • Buildroot: tl-expected
  • Yocto package: I couldn’t find one, but it would be trivial to make a .bb file.

json for modern c++:

lmdbxx:

  • Requires the lmdb package.
  • Buldroot: No package lmbd or lmdbxx package, but both are trivial to add.
  • Yocto: No lmdbxx package, but there is a lmdb package trivial to add as a recipe to the meta-mender project.

optional-lite:

  • Buildroot: No package, trivial to add.
  • Yocto: No package, trivial to add as a recipe to the meta-mender project.

tiny-process-library:

  • Buildroot: No package, trivian to add.
  • Yocto: No package, trivial to add as a recipe to the meta-mender project.

In fact, I have already ported all the packages in vendor/ to buildroot found here

There are many pros and cons to removing the vendored directory, most of which boil down to the maintenance of keeping the packages up to date, the extra size of the vendor packages, and the complexity of compiling them instead of simply depending on them.

1 Like
2

Hi @aduskett,

Thanks so much for sharing the idea and even creating an PoC already. As you already pointed out, I can also see pros and cons. Looping in @kacf, who leads the C++ client effort.

Greets,
Josef

3

Thanks @aduskett!

expected is in C++23. I don’t think it’s worth making this optional because support for it essentially ended in 2023, and C++23 “takes over” afterwards, which comes with recent g++ versions. We do need changes to actually use the C++23 version though, but this is mostly at the code level, and should be dependent on which C++ standard you use, not on system libraries. See optional also.

Yep!

There actually is an liblmdb++-dev package in Ubuntu, but it doesn’t work. We already depend on the lmdb package in Yocto.

This is actually optional already, it just isn’t very obvious. If you compile with C++17 or later, then this dependency isn’t used. See this commit.

Yep!

In general I agree that the dependencies should be optional, for exactly the reasons you mention. But all of them were added as vendored dependencies exactly because they are not easily available everywhere. So it’s not a priority for us to change it, since this approach is what we chose to be maximally compatible. That being said, I certainly don’t think we should stand in the way if others want to put in the work to make them optional.

1 Like
4

Thanks for the detailed reply! Making them optional seems like a pretty easy strategy. I can run with that today and tomorrow and make a PR!

1 Like