Re: [PATCH 1/3] t/lib-httpd: dynamically detect httpd and modules path

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> In order to set up the Apache httpd server, we need to locate both the
> httpd binary and its default module path. This is done with a hardcoded
> list of locations that we scan. While this works okayish with distros
> that more-or-less follow the Filesystem Hierarchy Standard, it falls
> apart on others like NixOS that don't.
>
> While it is possible to specify these paths via `LIB_HTTPD_PATH` and
> `LIB_HTTPD_MODULE_PATH`, it is not a nice experience for the developer
> to figure out how to set those up. And in fact we can do better by
> dynamically detecting both httpd and its module path at runtime:
>
>     - The httpd binary can be located via PATH.
>
>     - The module directory can (in many cases) be derived via the
>       `HTTPD_ROOT` compile-time variable.
>
> Refactor the code to do so. If runtime detection of the paths fails we
> continue to fall back to the hardcoded list of paths.

Hmph.

I do not think we would want to punish the distros that follow the
FHS that was created explicitly to help developers by standardizing
locations of various things, with an approach this patch takes that
throws everthing with bathwater and rely on $PATH first.

Would it be sufficient to please NixOS if we simply append $(command
-v apache) or whatever after the well known candidate locations?

I know "command -v" is in POSIX, and on both bash and dash (the two
shells most distros use), it works as this patch expects, but its
portability is also a bit worrysome, especially because the whole
point of this patch is to support a platform that is, eh, on the
fringe.

So, I dunno.