Currently, merily inheriting the meson eclass forces a dependency on meson. This is a problem if support for building with meson is only optional: it might depend on the architecture and/or use-flags whether building with meson makes sense or is perhaps even impossible (e.g. with USE=prefix this might not work). An example: >=app-portage/eix-0.32.11 will probably support building with meson or autotools, alternatively. The solution in autotools.eclass to a similar problem is to omit the dependency if AUTOTOOLS_AUTO_DEPEND=no is set. (The dependency is stored in AUTODOOLS_DEPEND anyway, but not forcefully added to DEPEND.) It would be nice if the meson.eclass would adapt an analogous mechanism.
I think we need a better use case for this before extending the eclass. I would not expect the same ebuild to support building with both autotools and meson.
Also, autotools.eclass is a bad example; that eclass is mainly used for eautoreconf, which ebuilds may or may not need to call. I would expect that every ebuild which inherits meson.eclass will end up calling meson_src_configure. If you have an example where this is not the case, please present it.
I have no real life example but what if some package provides some optional feature that requires meson to build but not the rest of the package?
(In reply to Lars Wendler (Polynomial-C) from comment #3) > I have no real life example but what if some package provides some optional > feature that requires meson to build but not the rest of the package? That seems very unlikely to me, and I would rather cross that bridge when we come to it.
(In reply to Mike Gilbert from comment #1) > I would not expect the same ebuild to support building with both autotools > and meson. I already wrote one (see below), and I am convinced that more will come: The two build systems cover almost disjoint use cases: meson is fast but very limited in what can be done. It is good for development and fast installation - *IF* it works. However, meson supports only a small number of systems. (E.g. it does not support any classical unix system which one might use with prefix). Moreover, many standard maintainer tasks are a pita to implement in meson (due to the philosophy that user functions are "bad"). So projects are almost forced to keep a system like autotools in parallel. And in fact, it seems that this is what most projects supporting meson do currently (appart from a few essentially linux-only projects like gnome or systemd). (In reply to Mike Gilbert from comment #1) > If you have an example where this is not the case The current alpha ebuild of eix for instance: https://github.com/vaeth/mv-overlay/blob/master/app-portage/eix/eix-0.32.11_alpha2.ebuild I would not dare to force meson and thus break eix on most prefix systems. On the other hand, why force all users to a long configure/compilation time when for most users it can be done much quicker? > Also, autotools.eclass is a bad example; that eclass is mainly used for > eautoreconf, which ebuilds may or may not need to call. The only reason not to do so is if one is forced to inherit due to _possible_ use-flag settting, but the actually chosen use-flags do not require it. This is exactly the same situation as with meson. The problem is that inherit's must not depend on useflags.
The prefix/non-prefix build for eix seems like a bad use case. Stick with autotools if you want portability, or ask for meson to be enhanced to fill the gaps.
(In reply to Mike Gilbert from comment #6) > The prefix/non-prefix build for eix seems like a bad use case. Stick with > autotools if you want portability, or ask for meson to be enhanced to fill > the gaps. (In reply to Martin Väth from comment #5) > The two build systems cover almost disjoint use cases: meson is fast but > very limited in what can be done. It is good for development and fast > installation - *IF* it works. > > However, meson supports only a small number of systems. (E.g. it does not > support any classical unix system which one might use with prefix). As both of us have said, work with the meson developers to fill the gaps. I think they would be pretty reasonable about it. > Moreover, many standard maintainer tasks are a pita to implement in meson > (due to the philosophy that user functions are "bad"). Upstream has several howtos wrt how to do common tasks with meson [1], and if you have a common task that they need to support, I'm sure they would be helpful. > So projects are almost forced to keep a system like autotools in parallel. > And in fact, it seems that this is what most projects supporting meson do > currently (appart from a few essentially linux-only projects like gnome or > systemd). Yes, projects are currently doing this, but I think it is part of a transition. I think more projects will drop autotools once meson supports more platforms. [1] http://mesonbuild.com/howtox.html
(In reply to Mike Gilbert from comment #6) > The prefix/non-prefix build for eix seems like a bad use case. Since when is choice and speed improvement a bad use case? > Stick with autotools if you want portability This certainly will happen in any case: As long as I can decide, autotools will never be removed from eix or its ebuild. The question is only if you really want to force all users of mainstream gentoo systems to waste their system's resources, only because you refuse to add 3 lines to an eclass, to allow using of meson _alternatively_ to autotools. > meson be enhanced to fill the gaps. Won't happen: : http://mesonbuild.com/Design-rationale.html : ###5. Must not add complexity due to obsolete platforms### : [...] If these old versions happen to work, great. If they don't, not a single : line of code will be added to the system [...] (Also the philosophy of non-Turing-completeness - which is the cause of the inconvenience of the system - is emphasized more than once.) Anyway, this whole discussion is completely off-topic. This bug is about a trivial 3 line patch to make an unfortunate side effect of inheriting an eclass optional. Your refusal to fix this trivial issue and instead demanding me to not use the eclass - de facto making all my many hours work of porting eix to meson superfluous, because nobody will be able use it - seems a strange reaction to me.
I am not aware of any current ebuild in the tree that allows the user to select the build system based on a USE flag. That is a weird idea. I am not convinced that the minor speedup provided by using meson where available is worth the added complexity of essentially duplicating every phase function in the eix ebuild. I do not find your use case compelling. William and I are of the opinion that without a compelling use case, we will not extend meson.eclass to make DEPEND optional. I am sorry that you have wasted your time writing a meson build file for eix. I hope you at least had some fun doing it. However, it just doesn't make a lot of sense for Gentoo.
> I am not aware of any current ebuild in the tree that allows the user to select the build system based on a USE flag Of course not, because it is not possible with the current meson.eclass. And other build systems probably do not have such orthogonal use cases that their alternative use is supported without a preference by upstream. But you are right that ideally "meson" should not be an ordinary USE-flag but an architecture dependency. Unfortunately, I lack the possibility of testing on many different architectures - that's why I have preliminarily introduced this new USE-flag to get possibly feedback through bugreports. Once it becomes clear where meson works, one could either hard-code the dependency in the ebuild or force-enable/disable this flag based on the profile. The latter has the advantage to leave e.g. a choice for prefix arches.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5f21d6aacd144e990402609aa3b3f118cc391447 commit 5f21d6aacd144e990402609aa3b3f118cc391447 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2017-10-04 19:03:18 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2017-10-04 19:30:08 +0000 meson.eclass: MESON_AUTO_DEPEND support Make it possible to use the meson eclass without it automatically adding meson to DEPEND. Intended for cases where meson usage is conditional (e.g. hidden behind a USE flag). This is a direct copy of the AUTOTOOLS_AUTO_DEPEND functionality & implementation from autotools.eclass, including the guard for multiple inheritance. Closes: https://bugs.gentoo.org/626054 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/meson.eclass | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)
commit 275c322a3304e6d25b1dc1a365135264785eb02c Author: William Hubbs <williamh@gentoo.org> Date: Sun Feb 3 18:52:00 2019 -0600 meson.eclass: remove meson_auto_depend Signed-off-by: William Hubbs <williamh@gentoo.org>
