| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This makes a makefile-driven developer workflow nicer.
|
| | |
|
| | |
|
| |\
| |
| | |
Fix fallout from #36275
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* trying to build emscriptenPackages not all fail
* reading the console.log it turns out python executable is not in place and that is why emconfigure didnt work
* backup commit
* much more targets are compiling now
* added common revisioning
* revision bump to 1.37.36 (not tested)
* fixed xmllint
* forcing unit testing, will implement the tests after i get home
* json_c test working
* added tests
* tiny fixes
* added documentation
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involved:
* Installing miniperl as $dev/bin/perl
* Setting miniperl to take INC from
lib/perl5/{site_perl/,}cross_perl/${version} as well as
lib/perl5/{site_perl/,}/${version}/${runtimeArch}, in that
order. miniperl taking from runtimeArch is not really correct, but
it works in some pure-perl cases (e.g. Config.pm) and can be
overridden with the cross_perl variant.
* Installing perl-cross's stubs into
$dev/lib/perl5/cross_perl/${version}
* Patching MakeMaker.pm to gracefully degrade (very slightly) if B.pm
can't be loaded, which it can't in cross-compilation.
* Passing the right build-time and runtime perls to Makefile.PL
|
| |
|
|
|
|
|
|
|
| |
Existing "mips64el" should be "mipsel".
This is just the barest minimum so that nixpkgs can recognize them as
systems - although required for building individual derivations onto
MIPS boards, it is not sufficient if you want to actually build nixos on
those targets
|
| |
|
|
|
|
|
|
|
|
|
| |
(#35171)
* buildRustCrate: adding a symlink from libblah-xxxxx.so to libblah.so
* BuildRustCrate: overriding phases
* Carnix: 0.6.5 -> 0.6.6
* Fixing symlink_dependencies --buildDep
* Shorter symlink_dependencies
* running `runHook postBuild` *after* the build
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I originally wrote this for packaging proprietary games in Vuizvui[1]
but I thought it would be generally useful as we have a fair amount of
proprietary software lurking around in nixpkgs, which are a bit tedious
to maintain, especially when the library dependencies change after an
update.
So this setup hook searches for all ELF executables and libraries in the
resulting output paths after install phase and uses patchelf to set the
RPATH and interpreter according to what dependencies are available
inside the builder.
For example consider something like this:
stdenv.mkDerivation {
...
nativeBuildInputs = [ autoPatchelfHook ];
buildInputs = [ mesa zlib ];
...
}
Whenever for example an executable requires mesa or zlib, the RPATH will
automatically be set to the lib dir of the corresponding dependency.
If the library dependency is required at runtime, an attribute called
runtimeDependencies can be used to list dependencies that are added to
all executables that are discovered unconditionally.
Beside this, it also makes initial packaging of proprietary software
easier, because one no longer has to manually figure out the
dependencies in the first place.
[1]: https://github.com/openlab-aux/vuizvui
Signed-off-by: aszlig <aszlig@nix.build>
Closes: #34506
|
| |\
| |
| | |
haskell: Recommend use of hoogle --local
|
| | |
| |
| |
| | |
This works around the browser security restriction of
disallowing links from http:// to file://.
|
| |\ \
| | |
| | | |
emacs-packages: Cleanup and document for overrides
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This removes some stale code that was a no-op for some time and adds
some docs/examples to help people with explicitly and consistently
choosing versions of some emacs packages (to help with problems
similar to #27083).
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
It should be in a <programlisting>, not <command>, tag.
|
| | | |
| | |
| | |
| | |
| | | |
The `name` attribute is filled in when `pname` and `version` are specified.
See https://github.com/NixOS/nixpkgs/pull/31173
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
compiling
I hope this will be a temporary measure. If there is consensus around
issue #33599, then we can follow an explicit `dontCheck`, but default to
not checking during cross builds when none is given.
|
| |\ \ \
| |_|/
|/| | |
Make cross compilation elegant
|
| | | |
| | |
| | |
| | | |
An excellent suggestion from @bgamari
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This accounts for all the new dependencies and propagation logic changes
I'm about to add.
Fixes #1915---with this change I think the distinction is finally clear
enough.
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
docs: clarify package and module option naming
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This attempts to briefly clarify the current naming conventions of
attribute names in `all-packages.nix` and module option names.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ /
|/| | |
|
| |\ \ \ |
|
| | |\ \ \ |
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Shrunk the CC Wrapper documentation so as not to be repetative.
|
| | |_|/ / /
|/| | | | |
|