My personal project and infrastructure archive
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
nomicon/pkgs/development/libraries/boost/default.nix

51 lines
1.4 KiB

boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
3 years ago
{ lib
, callPackage
, boost-build
, fetchurl
}:
let
# for boost 1.55 we need to use 1.56's b2
# since 1.55's build system is not working
# with our derivation
useBoost156 = rec {
version = "1.56.0";
src = fetchurl {
url = "mirror://sourceforge/boost/boost_${lib.replaceStrings ["."] ["_"] version}.tar.bz2";
sha256 = "07gz62nj767qzwqm3xjh11znpyph8gcii0cqhnx7wvismyn34iqk";
};
};
makeBoost = file:
lib.fix (self:
callPackage file {
boost-build = boost-build.override {
# useBoost allows us passing in src and version from
# the derivation we are building to get a matching b2 version.
useBoost =
if lib.versionAtLeast self.version "1.56"
then self
else useBoost156; # see above
};
}
);
in {
boost155 = makeBoost ./1.55.nix;
boost159 = makeBoost ./1.59.nix;
boost160 = makeBoost ./1.60.nix;
boost165 = makeBoost ./1.65.nix;
boost166 = makeBoost ./1.66.nix;
boost167 = makeBoost ./1.67.nix;
boost168 = makeBoost ./1.68.nix;
boost169 = makeBoost ./1.69.nix;
boost170 = makeBoost ./1.70.nix;
boost171 = makeBoost ./1.71.nix;
boost172 = makeBoost ./1.72.nix;
boost173 = makeBoost ./1.73.nix;
boost174 = makeBoost ./1.74.nix;
boost175 = makeBoost ./1.75.nix;
boost177 = makeBoost ./1.77.nix;
boost178 = makeBoost ./1.78.nix;
boost179 = makeBoost ./1.79.nix;
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
3 years ago
}