Merge ufo filters

[MarcusZuber]

First attempt to merge ufo-core and ufo-filters.

• CMake build
• Meson build
• Docs
• tests
  Tests will require filters. This allows to use filters in tests without any additional precautions.
• debian
• automated tests (gh-actions?))

[matze]

Controversial question: why not take the opportunity and finally drop CMake? Back then we maintained both because @picca was not convinced of meson's state. However, nowadays most high profile Linux infrastructure code (GLib, GNOME, Mesa, …) is using meson so from a packaging point of view it should not be an issue anymore.

P.S.: I would not try to preserve any commits but just dump the files. For archival reasons, just don't delete ufo-filters 😄

[MarcusZuber]

P.S.: I would not try to preserve any commits but just dump the files. For archival reasons, just don't delete ufo-filters smile

OK, this will make it easier. But I'm a little proud, that I managed to preserver the history ;-)

[MarcusZuber]

Controversial question: why not take the opportunity and finally drop CMake? Back then we maintained both because @picca was not convinced of meson's state. However, nowadays most high profile Linux infrastructure code (GLib, GNOME, Mesa, …) is using meson so from a packaging point of view it should not be an issue anymore.

I just had to catch in the configs the case, that one could maybe not have a compiler implementing c++11. Are you sure meson is popular enough? I also suffered a lot with CMake but I think now I know how to deal with it ;-)

[matze]

Are you sure meson is popular enough?

I know CMake is popular among C++ devs but anything core Linux seem to be betting on meson, so I doubt it's going anywhere. And yes, I was also able to deal with CMake but it just is a bad build system with an even worse "type" system and horrendous documentation. But no matter who decides what, maintaining two build systems is probably not the most productive activity to spend time on.

[llohse]

Since we are trying to get ufo and tofu running on Centos and the build system and dependencies being the main issues, let me try to give you an outside perspective.

I was quite surprised that you support two somewhat modern (compared to autotools) build systems. Having two is actually a bit confusing because you can never be sure which one is better maintained or tested. So for accessibility, it might be even better to settle with a single and well-tested build system. I believe that both options are supported well enough over all relevant platforms to not exclude potential users by dropping the other.

Undoubtedly, the choice between CMake and meson is very opinionated. Personally, I find both acceptable. Some facts to consider.

In the Python world, scipy and numpy are moving to meson: https://labs.quansight.org/blog/2021/07/moving-scipy-to-meson/, but CMake has strong supporters, too https://iscinumpy.gitlab.io/post/scikit-build-proposal/.
(I find myself in the dilemma which build system to use for my python bindings in C++.)

I noticed, that you use an ancient version of CMake - version 2.8. This could explain some of your sentiments, @matze, because "modern CMake" is supposedly very different from old CMake. This page on modern CMake recommends at least CMake 3.4 https://cliutils.gitlab.io/modern-cmake/chapters/intro/dodonot.html. However, exploiting modern CMake would probably require a rewrite of most your build config.

[matze]

I noticed, that you use an ancient version of CMake - version 2.8. This could explain some of your sentiments, @matze, because "modern CMake" is supposedly very different from old CMake.

Fair enough, although they never dropped their stringly types. By the way, for a long time we stuck with older CMake in order to support long-term distributions like CentOS. But yes, in the mean time this could have been lifted. Anyhow, don't make the decision depend on me, I don't have any stakes in the further development anyway.

[MarcusZuber]

I would propose to first stay with both, since I don't see something fundamental to show up, that we did not yet solve with CMake.
If we change or add something, that would require much work on the build system we should considered dropping CMake.

[tfarago]

Yes a million times to dropping CMake, who has time for things like in ufo-kit/uca-net#15?

[llohse]

This should either be renamed to something like filterconfig.h or merged with the ufo-core config.h since during compilation of the filters both files will be present in the include path.

[llohse]

deps does not seem to be defined so it will use the value from ufo-core, which has the wrong dependencies
Should have something like

deps = [
    lib_dep,  // from ufo-core/ufo/meson.build
    opencl_dep,
    m_dep,
]

[tfarago]

automated tests (gh-actions?))

yes please, at least Ubuntu and CentOS

[llohse]

Any updates on this?

[tfarago]

Sorry, not yet. Postponing to early 2023.

[MarcusZuber]

Yes, I plan to proceed with this early next year. I have an almost working version in my local installation.

[tfarago]

How about merging also tofu? On its own it's pretty useless and having the core, the filters and the tools in one package will simplify installation for everyone.

[llohse]

How about merging also tofu? On its own it's pretty useless and having the core, the filters and the tools in one package will simplify installation for everyone.

From my (user's) point of view, installing tofu is simple enough as it is -- once core and filters are installed. As I see it, combining it into a single tree would not really simplify the installation, since tofu is installed most easily via pip anyway.

On a different note: Is this MR still being worked on? It felt like it was 95% finished a year ago.

[tfarago]

Yes, that's true, but wouldn't it be nice to just do this on a fresh system installation (now I am putting myself into the ignorant shoes not considering all the prerequisites)?

pip install ufo-tofu
ufo-launch ...
tofu reco ...

It's not being worked on, I would say it's being "though about".