Remove all FetchContent from CMake

[marcusmueller]

Can't do FetchContent in any distro builds, nor in openembedded, Conan/artifactory builds etc. Simply a show-stopper for distribution, and thus for a 4.0 release.

We need all externalities to either be packaged or package them ourselves. Thus, external sources without proper release versions get a 🔴 , and us not using an explicit release but either just "get HEAD" or a git commit hash gets a 🔴 .

name	URL	external: release hygiene?	using release?	available in debian?	conan?	remark
pffft	https://github.com/fair-acc/pffft.git	🔴 (upstream: also 🔴 )	🔴	🔴	🔴 (upstream: 🟡 )	can we upstream changes and invite upstream to release?
boost-external ut	https://github.com/boost-ext/ut.git	🟢	🔴	🔴 (but Fedora)	?	why are we using a random git commit?
vir-smd	https://github.com/mattkretz/vir-simd.git	🟢	🟢	🔴	🔴	@mattkretz
cpp-httplib	https://github.com/yhirose/cpp-httplib.git	🟢	🟢	🟢	🟢	should immediately be unvendored; ninja install breaks system installation
pmt	https://github.com/gnuradio/pmt.git	🔴	🔴	🔴	🔴	@jsallay we should sit down together and make this a proper lib with proper releases and packages, and a bit of publicity for GR4. @maitbot are you interested in helping us get this into debian?

[mattkretz]

On pffft … we could try. But I suspect our changes are going too far. (Upstream is C and we turned it into C++ and replaced their SIMD "abstraction".) If that's the case then we would need to fork it and call it something else, no?

On vir-simd … is there anything I could/should do?

[RalphSteinhagen]

@mattkretz nothing on your side. We will proceed as we discussed earlier at work.

[RalphSteinhagen]

• pffft: we have a <simd> version (WIP, needs clean-up) for it that we will incorporate to the core (see also here.

• boost-external ut: this is only needed for the CI (unit-tests). N.B. has nothing realy to do with 'boost' but in naming.

• vir-smd: it's a tiny wrapper that we could inline as third_party dependency. Will gradually fade out with increasing GCC (already quite good) and LLVM (soso, via wrapper) support.

• cpp-httplib: we'll replace this soon (on our roadmap here) and (the replacement) will become an optional dependency only for the block-lib. See also #658

• pmt: needs some more work w.r.t. QA, Python interfaces (underlying technology tbd.), replacing rva::variant<> with another custom type-safe abstraction, and whether there are other than GR4-core usages for those packages.

[jsallay]

A few notes: I am working on the pmt library to clean up its dependencies to make it easier to package. boost-external ut and cpp-httplib are either already in package managers or very easy to add. Vir-simd appears to be pretty easy to package up as well (and is already available in my package manager of choice). I haven't looked at what you have done with pfft yet, but it sounds like that is the most complicated aspect of packaging here.

[jsallay]

Also @marcusmueller, conan has all of these deps except for pmt - so we could update the chart.