| Commit message (Collapse) | Author | Age |
|
|
|
| |
https://crates.io/crates/evcxr/0.5.0
|
|\
| |
| | |
pypy: fix build on darwin
|
| | |
|
| |
| |
| | |
perl.withPackages did not allow to add more packages using $PERL5LIB
|
|/ |
|
| |
|
|
|
|
|
| |
This is a hook that loads a virtualenv from the specified `venvDir`
location. If the virtualenv does not exist, it is created.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In "perl: fuse configureFlags" [1] the effects of the preConfigure
phase were merged into configureFlags. After this change values with
spaces do not reach the configure script intact.
The only flag this affects is `ldflags` for Aarch32 and Mips, and perl
builds without it on armv7l-linux so it's probably no longer required
on any platform.
Fixes:
configuring
configure flags: -de -Dcc=cc <...> -Dldflags=\"-lm -lrt\"
./Configure: eval: line 1677: unexpected EOF while looking for matching `"'
./Configure: eval: line 1678: syntax error: unexpected end of file
Configure: unknown option -lrt"
[1] 3b50d0462a4174bb155b258a32ab1ab4176ba2fc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In "perl: fuse configureFlags" [1] the effects of the preConfigure
phase were merged into configureFlags. After this change values with
spaces do not reach the configure script intact.
The only flag this affects is `ldflags` for Aarch32 and Mips, and perl
builds without it on armv7l-linux so it's probably no longer required
on any platform.
Fixes:
configuring
configure flags: -de -Dcc=cc <...> -Dldflags=\"-lm -lrt\"
./Configure: eval: line 1677: unexpected EOF while looking for matching `"'
./Configure: eval: line 1678: syntax error: unexpected end of file
Configure: unknown option -lrt"
[1] 3b50d0462a4174bb155b258a32ab1ab4176ba2fc
|
| | |
|
| |
| |
| |
| |
| | |
This makes RbConfig["CC"] return an invalid path, but I hope nothing
is depending on that anyway...
|
| | |
|
|\ \
| | |
| | | |
picolisp: 19.6 -> 19.12
|
| |/ |
|
| | |
|
|/ |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
| |
| |
| | |
https://github.com/google/evcxr/releases/tag/v0.4.6
|
|\| |
|
| |\
| | |
| | | |
stdenv, haskell: bonafied GHCJS cross compilation without stdenv.cc
|
| | |\ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before, we'd always use `cc = null`, and check for that. The problem is
this breaks for cross compilation to platforms that don't support a C
compiler.
It's a very subtle issue. One might think there is no problem because we
have `stdenvNoCC`, and presumably one would only build derivations that
use that. The problem is that one still wants to use tools at build-time
that are themselves built with a C compiler, and those are gotten via
"splicing". The runtime version of those deps will explode, but the
build time / `buildPackages` versions of those deps will be fine, and
splicing attempts to work this by using `builtins.tryEval` to filter out
any broken "higher priority" packages (runtime is the default and
highest priority) so that both `foo` and `foo.nativeDrv` works.
However, `tryEval` only catches certain evaluation failures (e.g.
exceptions), and not arbitrary failures (such as `cc.attr` when `cc` is
null). This means `tryEval` fails to let us use our build time deps, and
everything comes apart.
The right solution is, as usually, to get rid of splicing. Or, baring
that, to make it so `foo` never works and one has to explicitly do
`foo.*`. But that is a much larger change, and certaily one unsuitable
to be backported to stable.
Given that, we instead make an exception-throwing `cc` attribute, and
create a `hasCC` attribute for those derivations which wish to
condtionally use a C compiler: instead of doing `stdenv.cc or null ==
null` or something similar, one does `stdenv.hasCC`. This allows quering
without "tripping" the exception, while also allowing `tryEval` to work.
No platform without a C compiler is yet wired up by default. That will
be done in a following commit.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When `makeWrapperArgs` variable is not set, `declare -p makeWrapperArgs`
will return with 1 and print an error message to stderr.
I did not handle the non-existence case in b0633406cb70e0e4ae3470a6b49e32b38d99ac16
because I thought `mk-python-derivation` will always define `makeWrapperArgs`
but `wrapProgram` can be called independently. And even with `mk-python-derivation`,
`makeWrappers` will not be set unless explicitly declared in the derivation
because of https://github.com/NixOS/nix/issues/1461.
I was lead to believe that because the builds were succeeding and I confirmed
that the mechanism fails when the variable is not defined and `-o nounset` is enabled.
It appears that `wrapPython` setup hook is not running under `-o nounset`, though,
invaldating the assumption.
Now we are checking that the variable exists before checking its type, which
will get rid of the warning and also prevent future error when `-o nounset`
is enabled in the setup hook.
For more information, see the discussion at
https://github.com/NixOS/nixpkgs/commit/a6bb2ede232940a96150da7207a3ecd15eb6328
|
| | | |
| | | |
| | | |
| | | | |
This fixes the rubyMinimal package.
|
| | | | |
|
| | | | |
|
| | | | |
|
|\| | | |
|
| |\ \ \ |
|
| | | | | |
|
|\| | | | |
|
| |\| | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Release notes: https://www.ruby-lang.org/en/news/2019/12/25/ruby-2-7-0-released/
|
| | | | |
| | | | |
| | | | |
| | | | | |
Changelog: https://blog.rubygems.org/2019/12/20/3.1.2-released.html
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Similar to `gitMinimal` or `pythonMinimal`, this is useful for scripts
which don’t use anything but the standard library and want a small
footprint.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Reduces the runtime closure by ~200MB if enabled.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Bash takes an assignment of a string to an array variable:
local -a user_args
user_args="(foo bar)"
to mean appending the string to the array, not parsing the string into
an array as is the case when on the same line as the declaration:
local -a user_args="(foo bar)"
b0633406cb70e0e4ae3470a6b49e32b38d99ac16 extracted the declaration before
the newly branched code block, causing string makeWrapperArgs being added
to the array verbatim.
Since local is function scoped, it does not matter if we move it inside
each of the branches so we fix it this way.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
python.pkgs.wrapPython: fix makeWrapperArgs
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When `makeWrapperArgs` is a Bash array, we only passed the first
item to `wrapProgram`. We need to use `"${makeWrapperArgs[@]}"`
to extract all the items. But that breaks the common string case so
we need to handle that case separately.
|
|\ \ \ \ \ \
| | |/ / / /
| |/| | | | |
|
| |\ \ \ \ \
| | | |/ / /
| | |/| | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I've built several versions without issue.
|