Support building the manual without make install

[jhgit]

This changes make target pre-requisites to point to build products within the working area instead the installed location.

Without this, 'gmake all' will hit a dependency on $(bindir)/nix and try to install it (which will normally fail if building as a regular user).

Fixes #7360 (Build fails ... /usr/local/lib/libnixutil.so: Permission denied)

Motivation

Allow full build as regular user. Avoid requiring install when just doing 'gmake all'

Context

Fixes #7360

Checklist for maintainers

Maintainers: tick if completed or explain if not relevant

• agreed on idea
• agreed on implementation strategy
• tests, as appropriate
  • functional tests - tests/**.sh
  • unit tests - src/*/tests
  • integration tests - tests/nixos/*
• documentation in the manual
• code and comments are self-explanatory
• commit message explains why the change was made
• new feature or incompatible change: updated release notes

[jhgit]

I should add there was a change here that helps support different sed(1) implementations (for the non-portable -i feature).
sed -i is not defined by POSIX, and BSD sed's implementation of -i is parsed differently than GNU sed. Using '-i.ext' works with both GNU & BSD sed, whereas '-i' by itself or '-i ""' does not.

To that end, adding something like the following to the commit message seems reasonable:

While here, use 'sed -i' in a way that is compatible with both BSD and GNU sed implementations.

An alternative to using sed -i at all is to not rely on the less portable -i feature at all. Something like what -i does under the covers (create a temp file):
for ff in $@.tmp/*.md; do sed 's^@doctroot@^../..^g' "${ff}" > "${ff}.tmp"; mv "${ff}.tmp" "${ff}"; done
That's a little more clumsy than using sed -i, but is more portable. And it's not quite as efficient as sed -i, but this should not be noticeable in this case.

[jhgit]

While this is waiting for a review, it would be helpful for someone with triage access to add the 'build problem' label.

[fricklerhandwerk]

@jhgit thanks for your patience, and sorry for the delay. I think this is quite important, but we don't have the routine of sweeping up incoming PRs into the team's triage process. I do it sometimes and irregularly when I find a few minutes. I hope merging #6338 and aggressively prioritising by label will help...

[Ericson2314]

@jhgit I recommend pulling the path to the Nix binary to be used into a make variable.

While this better for this PR, something @roberth at least has been pursuing is fine-grained derivations, for sake of quicker rebuilds etc. That would require changing that path to neither it's old or new value, but an external pre-built Nix in the Nix store.

The only way we can support both use-cases with some more indirection in the form of a variable. So let's start there.

[Ericson2314]

(The build failure looks unrelated: it would appear that handleSQLiteBusy's logWarning call is still doing too much error:and not enoughwarning:and so thegrep` is not properly filtering it out. I suspect #7865 will help with this.)

For now, just ignore it, hopefully it goes away next time.

[roberth]

handleSQLiteBusy is just silly.

• SQLite busy reporting is broken #7998

Indeed @Ericson2314's explanation seems sufficient and this does not seem like a relevant error.

[Ericson2314]

Triaged in the Nix team meeting:

• build manual w/o Nix
• assigned to @Ericson2314

[Ericson2314]

@jhgit Please use the factored-out variable. When you rebase and push again the error will probably go away.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-03-10-nix-team-meeting-minutes-39/26279/1

[Ericson2314]

Closing as duplicate of #5145