On Mon, May 9, 2022 at 1:13 PM orbea <or...@riseup.net> wrote: > > On Mon, 9 May 2022 10:59:03 -0400 > Mike Gilbert <flop...@gentoo.org> wrote: > > The NINJA environment variable is used directly by meson and may > > contain an absolute path. I don't think it makes sense to restrict > > possible values to just "ninja" and "samu". That will make it more > > difficult for users to override it with a local copy of either tool, > > or to use a different implementation should someone write one in the > > future. > > > > It might make sense to introduce a different eclass variable to > > control NINJA_DEPEND and the default value for NINJA. > > The game antares (https://github.com/arescentral/antares) has a custom > python based build system that also respects the NINJA variable. > > Your point is a good one, but I'm unsure how this would work? The > NINJA_DEPEND variable has to be set to a valid package elsewhere in the > eclass scripts, for example the 'has_version -b' check in the cmake > eclass. > > Allowing the user to set an arbitrary value will require they also > being able to set NINJA_DEPEND to a correct value. In some of these > cases there may not be an applicable ebuild to set it to even. Maybe > I'm missing something, but this seems like a good way to complicate the > process and possibly introduce pebkac. Maybe it would be preferable to > just add additional ninja implementations to the list as they are > available? > > Also if its just testing local versions I think it could be worked > around by setting the PATH and / or using symlinks? A user could > create a dummy ebuild as well.
We could make the eclass ewarn on unknown NINJA values, and set NINJA_DEPEND to empty in that case. Just don't call "die". That would allow users to override NINJA without triggering a failure, and still alerts ebuild maintainers in case they make a typo when setting NINJA in an ebuild.
