It turns out that cargo implicitly depends on rustc at runtime: even
`cargo help` will fail if rustc is not in the PATH.
This means that we need to wrap the cargo binary to add rustc to PATH.
However, I have opted into doing something slightly unusual: instead of
tying down a specific cargo to use a specific rustc (i.e., wrap cargo so
that "${rustc}/bin" is prefixed into PATH), instead I'm adding the rustc
used to build cargo as a fallback rust compiler (i.e., wrap cargo so
that "${rustc}/bin" is suffixed into PATH). This means that cargo will
prefer to use a rust compiler that is in the default path, but fallback
into the one used to build cargo only if there wasn't any rust compiler
in the default path.
The reason I'm doing this is that otherwise it could cause unexpected
effects. For example, if you had a build environment with the
rustcMaster and cargo derivations, you would expect cargo to use
rustcMaster to compile your project (since rustcMaster would be the only
compiler available in $PATH), but this wouldn't happen if we tied down
cargo to use the rustc that was used to compile it (because the default
cargo derivation gets compiled with the stable rust compiler).
That said, I have slightly modified makeRustPlatform so that a rust
platform will always use the rust compiler that was used to build cargo,
because this prevents mistakenly depending on two different versions of
the rust compiler (stable and unstable) in the same rust platform,
something which is usually undesirable.
Fixes#11053
Also prepare to support multiple stage1 flavors.
The 'host' flavor would be preferred to reuse systemd components instead
of downloading/unpacking/processing a CoreOS PXE image.
This update was generated by hackage2nix v20150922-42-g3ca1747 using the following inputs:
- Nixpkgs: ad0723f0c7
- Hackage: c7478af457
- LTS Haskell: 8ec1fc3419
- Stackage Nightly: e6bcfb640c
Regression introduced by 050bebb8c4.
It's essentially an upgrade to CMake 3.4.0, which breaks the build
because it seems that in CMake 3.3.x, the check_include_files() command
was implicitly included (haven't found out about why exactly).
So we're now just adding an import for CheckIncludeFiles in addition to
CheckIncludeFile, so that we have both commands (the plural and the
singular variant) available.
My original goal was to use brndnmtthws/conky@3a574ba, but this breaks
the build as well, because check_include_files doesn't accept additional
compile flags.
However, this is needed if building with wireless support, because
including iwlib.h needs -D_GNU_SOURCE set and check_include_files
doesn't do that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
