[Makefile/all] Possible mismatch in the install location of libdirs #1930

Problem

The $PREFIX directory is used for defining the default value for libdir, which some tools use to retrieve data such as cat files, or .c and .h files; and for installing these files. These happen on different stages: make and make install, respectively. There is no mechanism put in place to enforce the same value for the parameter when executing these commands. This means that when changing the location of the installation, the execution of make needs to be changed as well.

Options:

1. Change make install to execute the rule make.
2. Change how the PREFIX is used for libdir to be embed as part of only make install, instead of generation of version.ml
3. Add a configure executable, so both make and make install use the same PREFIX
4. Add PREFIX into a configuration file that gets read by the binaries that need to use libdir.

Option 1

After searching for best practices regarding the relation between make and make install. The consensus seems to be that separate make from make install is better because install might required elevated privileges, and make should be run with a fewer privileges as possible.

Option 2

It's unclear how to do this, dune provides facilities to brand information on release workflows; and has code that is generated just before link time to inject some information.
The first branding is text substitution on the plain text files in the repository. It substitutes a placeholder for the actual value. It happens when running dune subst, some tools integrate it, like dune-release. dune subst could be run as part of make install to make sure this information is always present in the installed executables, but it has the downside that it modifies the files in the repository, so it's not fit for development purposes.

The second branding is able to avoid the writing of the source tree, and it happens both when a an executable is being installed, or when promoting its .exe to the source tree. This needs the executable to depend on the special OCaml library dune.build-info, which has special handling within dune.

Unfortunately dune does not support arbitrary strings in either of these, only predefined ones, so this seems only suitable for introducing the version.
https://dune.readthedocs.io/en/latest/usage.html#dune-subst
ocaml/dune#2224

Option 3

Adding a configure executable that enforces the parameters for make is doable through an ocaml binary, using dune to trigger the compilation and execution.
The issue is that this adds a new command to add before compiling the project, even if this has been the standards in autoconf-based projects. (./configure && make && make install)

Option 4

This will need to set up a well-defined hierarchy of directories and files to read and produce the code so all executables can apply it, so it will need both more code and time for testing.

personally, I prefer the third option, as the downsides seem less egregious to me than the other option, which is running a command after cloning.