Add a --path-prepend configure option

[shym]

Add a new option so that the toolchain can invoke commands with an extended PATH.
This is useful on macOS to be able to use homebrew’s llvm and lld packages (which we need to generate ELF unikernels) as they do not install the binaries in a directory in PATH to avoid conflicts with versions of the same tools provided by macOS.

Extracted from #656, based on #657 as they modify adjacent lines, and revised so that:

• the --path-prepend value is no longer expected to end with a separator (ie it’s expected not to),
• the --path-prepend option can be used multiple times, the entries are added to the PATH is the same order,
• when that option is not set, the toolchain tools won’t contain a weird looking PATH="$PATH" line.

I checked that this works as intended there.

[hannesm]

I still don't understand why this should be needed -- can't you "export PATH=/whatever:$PATH"? Why should a configure/build system do this for you?

[shym]

Here is a fairly common use case that shows the issue with the two compilers and toolchains on a macOS + homebrew.
To build a MirageOS Solo5 unikernel with some ppx you have:

• the OCaml/Solo5 cross compiler that will call the aarch64-solo5-... toolchain that must use the homebrew clang and tools,
• the standard (non-cross) OCaml compiler, used to compile the ppx, that will call the standard tools and expect to see the standard macOS ones it was built with.
  As, in the same build we want to use both toolchains, there’s no proper way to set PATH for it.

[hannesm]

Ok, so I stand at the point that modifying the PATH inside a build system isn't a very nice approach.

I think I get a glimpse of what you need: the "cross-compilation tools should refer to clang installed by homebrew". So, what prevents you from passing TARGET_CC, TARGET_LD, TARGET_OBJCOPY (or HOST_CC etc -- now I'm confused in which context you need what) to point to the (absolute) paths of the homebrew installation?

When I understand it correctly, the normal OCaml compiler from the opam switch is just there as usual -- and the ocaml-solo5 cross-compilation OCaml compiler will then use the x86_64-solo5-none-static-cc/ld/objcopy?