A single `dune-project` file can contain multiple packages that dune can
build. This is a problem, because the default dune build command we use
doesn't search through `dune-project` for dependencies, it assumes that
will have already been built and can be found with findlib. See
zipperposition for an example of this.
Adds a new `dunePackages` argument to allow this, defaulting to `[ pname ]`
for backwards compatibility.
Dune (in Coq lang mode) requires COQPATH, contrary to other tools such
as coq_makefile.
I used an AI for the last step: getting the suggestion of using
`preBuild` instead of `env`.
Assisted-by: Copilot:Claude Haiku 4.5
Two halves of how the compiler finds libstdc++.
The library was not on the link path. `wrapCCWith` was given
`libcxx = libstdcxx`, which tells cc-wrapper where the C++ headers live
but does not put the library where a GNU compiler looks, so every C++
link failed with `cannot find -lstdc++`. Add `-B${libstdcxx}/lib`, as
libgcc, libssp, libatomic and libgomp already are.
The headers had the opposite problem: found too eagerly, by the wrong
language. libstdc++ deliberately ships headers named after C headers --
`math.h`, `stdlib.h`, `complex.h`, `stdckdint.h`, `stdbit.h`,
`stdatomic.h`, `tgmath.h`, `fenv.h` -- whose purpose is to shadow the C
ones when compiling C++. Installed into `$dev/include` they shadowed
unconditionally, since `libcxx` is a propagated target-target dep of
cc-wrapper and the setup hook puts that directory on the **C** include
path of everything built with the compiler. Under C, libstdc++'s
`<stdckdint.h>` is an empty shell, so its functions vanish:
bash: braces.c: implicit declaration of function 'ckd_sub'
coreutils: randperm.c: implicit declaration of function 'stdc_bit_width'
Both build fine with monolithic GCC, whose libstdc++ headers live in
`include/c++/$ver` and are added by the g++ driver alone. Install them
into a sibling `include-cxx`, which keeps them off C's include path while
staying findable for C++; no version or target subdirectory is needed,
since the store path already separates one libstdc++ from another.
Assisted-by: Claude Code (Claude Opus 5)
I do not have the time or energy to handle all of this. Let alone my
GitHub notifications. This PR is in good faith and does not refer to
anything community-related. I will keep on doing nixpkgs work but the
pile of shame (let's call it that) needs to be cleaned. Thanks to
@mweinelt which whom I had a discussion and who made me aware of this
issue.
