search

ufo-kit / ufo-core

GLib-based framework for GPU-based data processing
GNU Lesser General Public License v3.0
24 stars 8 forks source link

Merge ufo filters #186

Open MarcusZuber opened 2 years ago

MarcusZuber commented 2 years ago

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

matze commented 2 years ago

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 :smile:

MarcusZuber commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

tfarago commented 2 years ago

automated tests (gh-actions?))

yes please, at least Ubuntu and CentOS

llohse commented 1 year ago

Any updates on this?

tfarago commented 1 year ago

Sorry, not yet. Postponing to early 2023.

MarcusZuber commented 1 year ago

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

tfarago commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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".