opam uses a sandbox for running builds and installs; then it copies files over to their final location.
if you don’t distinguish between build and install, then how can opam know what files are meant to be installed, and which are merely created as part of the build-process, right?
I think that’s the reason this matters. B/c otherwise, well, it really wouldn’t matter, would it?
P.S. But also, I have this nagging thought that maybe there’s some other way that opam distinguishes between “I built this file in the process of making the package” and “I built this file and put it its final location”, in which case, this distinction (for opam) is superfluous. But even if it were superfluous, having a distinction is a valuable form of documentation for people coming to your project and finding an error: they can do the “build” step knowing it won’t pollute installation-directories. I often look at the build-step in the opam file for just this reason.
I think even conceptually I don’t understand what install vs build means. For me it I am realizing I assume build means “compile the binaries needed for the project to work and put it in some location e.g. usally ~/.local/bin or /usr/bin for system ones” but that is what install means to me too. I just don’t know what the distinction is in opam since for me installing always just means compiling so it’s available for use.
Thanks for the discussion I think we are moving forward.
There is another way which is the reason why many packages do not sport an install: field in their opam file.
After building, opam looks at the root of the source directory for an a $(PKG).install file which declares which files need to be installed where. Your build system can generate this file. In this case your opam file just needs build: instructions. See the manual.