When authoring #220966, I missed that the `//` would take effect solely
in the else branch, fixing hledger-check-fancyassertions, but not
tests.writers.bin.haskell.
The check script needs to run at build time. Add a new argument to
makePythonWriter for the appropriate buildPackages version of pythonPackages,
and use this to run the check script.
Some haskell code starts silently hanging when not built with a
threaded runtime, so let’s assume people using `writeHaskell` don’t
care about micro-optimizations like this and do the expected thing.
Some architectures don’t support a threaded runtime, for these we
provide the `threadedRuntime` option to turn it off (it should fail at
build time in that case, easy to detect).
If somebody already passed `"-threaded"` before via ghcArgs, this
will not add the flag a second time. Thus it’s backward-compatible in
this regard.
I tested out both branches (with `-threaded` set and not set before),
on an example I had where the runtime would hang when not compiled
with `-threaded`.
This simplifies usages and makes the default value consistent.
In a few cases, the default value was interpreted to be `false`,
but this is useless, because virtually nobody will explicitly
set `allowAliases = true;`.
Uses fsharp interactive (fsi) to run fsx script
Expose mkNugetSource and mkNugetDeps functions
Use them in writers.writeFSharp and buildDotnetModule
Add tests
mach-o executables we produce in writers are not always fully valid for
some reason. In normal derivation this is fixed in fixupPhase and we can
replicate this behavior here easily.
Resolves#132660.
bintools points to the default bintools (e. g. cctools, binutils,
llvmPackages.bintools) for the next stage. So instead of using GNU
binutils' strip which may not support the current platform, we need to
use buildPackages.bintools-unwrapped.
Additionally we need to use `-S` over `--strip-unneeded` as the latter
is a GNU binutils-specific flag and not supported by cctools.
Also add the correct targetPrefix in order to support cross-compilation
correctly here at least.
This function is fundamentally broken.
Not even the ncurses example will compile.
The interface needs to be rethought for it to work (i.e. don't
unconditionally include all pc files, set include path and ld path and
rpath).
Since it is unlikely that in the current this has any user, just drop it for now.
Before this change, it was not possible to use string paths,
because then the `types.str.check` would succeed. So the only paths that
could be used were ones from the local filesystem via e.g.
`./some/path`.
We can easily fix this by using `types.path.check` instead to determine
whether we are dealing with a path.
This notably also allows using Nix-fetched sources as the content, e.g.
`fetchFromGitHub { ... } + "/some/file"`
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
