[LTP] [RFC PATCH 2/2] sched_football: Rewrite into new API
Petr Vorel
pvorel@suse.cz
Mon Jul 15 11:52:13 CEST 2024
> Hi!
> > I hoped there is something I just overlooked. Even I'm not a big fan of meson,
> > instead of implementing something own I would consider migrating to it.
> > Looking into Andrea's POV, where he did at least some work [1].
> I'm afraid that meson is not good choice for us. LTP has to be able to
> be compiled everywhere even on ten years old distribution and very
> restricted embedded devices, hence I would like us to stay on the most
> common and stable build system tooling out there. Which is plain old
> make.
Correct + not pushing for it now. FYI iputils compilation worked even on old
CentOS 7 (well, meson and ninja got over epel).
15-SP2 (IMHO the oldest distro LTP upstream cares) has meson 0.54.2 and ninja
1.10, these would be enough for initial support. Therefore once we bump the
support higher (next year), we *could* consider moving away from autotools
(obviously starting to ask on automated-testing@yoctoproject.org if somebody has
problems with the dependencies.
> And the main problem with our build system is not the tooling we choose,
> but the complexity imposed by the out-of-tree build implemented in the
> complex makefiles. As far as I can tell 99% of the problems would be
> solved by ripping out out-of-tree support, which would remove most of
> the code we have in there.
+1 for removal. I wonder if anybody finds a time to do that.
> > But back to the reality, would it be possible to merge this even with broken
> > dependency? I'm not sure myself.
> I will double check the code, before adding my final reviewed-by.
Thank you! It still bothers me that building sched_football does not trigger
building a library, but at least it will work for a full build (building whole
LTP).
> Also this is a step number one. I think that we should enable the
> realtime compilation by default and the sched_football should be added
> to the scheduller runtest file as well, so that it's executed by default
> as well.
+1, I'll have look into it.
Kind regards,
Petr
More information about the ltp
mailing list