* Only build static libs by default when stdenv.hostPlatform.isStatic
* Add separate -bin output
* Move h5hlcc/c++ dev binaries to -dev output
* Default to building with C++ support to cut down
on duplicated hdf5/hdf5-cpp in downstream closures
Albeit counter-intutive, the `propagatedBuildInputs`
mechanism and the corresponding package files in
`nix-support/propagated-build-inputs`
can form a dependency cycle.
This can happen if a package adds itself to this file,
or if multiple outputs of one derivation reference each other.
An example for this is the `patchPpdFilesHook`:
In its mission to collect dependency packages with binaries
that might be required by the dependent package to be created,
it sometimes picks up the dependent package itself.
This indicates that if a file of the dependent package
is used, the package itself should also be installed.
In the case of a multiple output package,
it is also possible that two outputs depend on each other,
creating a dependency cycle.
Since commit 2651ddc7b0,
the `find_packages` function in `catch_conflicts.py`
recursively collects all `propagated-build-inputs` files.
If it encounters a dependency cycle, it must not follow the
cycle to avoid infinite recursion (and a stack overflow).
The commit at hand adds a check so that the function skips over
a package that it already encountered and processed earlier.
This does not loosen the script's checks as the script
still recursively collects all propagated build inputs.
previously, when the lua setup hook found a system lua module,
it would simply add that library to LUA_PATH, meaning the default
path would no longer be used.
for luajit, this bug would always occur, due to it having
several inbuilt libraries such as luabitop.
lua5 still passed unit tests, simply because the test
environment doesn't include any system lua libaries,
but the bug would still occur if lua5 was used in a derivation with
a buildInput from luaPackages, since that package would be found by
the envHook and overwrite the default path.
now, the setup hook will use any system module paths in addition to
the default path, instead of overriding it.
Much like the previous commit that adds dependencies &
optional-dependencies this aligns PEP-517 build systems with how they
are defined in PEP-518/PEP-621.
The naming `build-system` (singular) is aligned with upstream Python standards.
Since https://github.com/NixOS/nixpkgs/pull/161835 we've had the
concept of `passthru.optional-dependencies` for Python optional deps.
Having to explicitly put optional-dependencies in the passthru attrset
is a bit strange API-wise, even though it semantically makes sense.
This change unifies the handling of non-optional & optional Python
dependencies using the names established from PEP-621 (standardized pyproject.toml project metadata).
There is an arbitrary mapping being done right now between
nixpkgs lua infrastructre and luarocks config schema.
This is confusing if you use lua so let's make it possible to use the
lua names in the nixpkgs, thanks to the lib.generators.toLua convertor.
The only nixpkgs thing to remember should be to put the config into `luarocksConfig`
`buildLuarocksPackage.extraVariables` should become `buildLuarocksPackage.luarocksConfig.variables`
