* Upstream recommends it (adding $QUARTUS_ROOTDIR/bin to $PATH).
* It's cool that nixpkgs *can* do these tricks (only expose a subset of
programs), but in this case I don't think it's a good idea. For
example, before this change I was missing the `jtagconfig` program.
* This increases the number of programs in .../bin from 29 to 80.
(In preparation for adding lmutil.)
Quartus is a mix of 32- and 64-bit programs, and these "lsb" loaders are
required by some of the unwrapped binaries:
$ find /nix/store/HASH-quartus-prime-lite-unwrapped-20.1.1.720 -type f -executable | xargs -n1 patchelf --print-interpreter |& grep "ld-lsb" | sort -u
/lib64/ld-lsb-x86-64.so.3
/lib/ld-lsb.so.3
Upper case shell variables are generally for internal variables (SHELL,
BASH_VERSION) or environment variables (PAGER, EDITOR). Other variables
should be lower case.
Instead of maintaining both a list of executables to wrap and their
directory names, extract the directory names from the executables and
run mkdir as needed. Keep DRY.
Turns out Rider was previously relying on having libstdc++ in
LD_LIBRARY_PATH, because the binaries were not patched properly.
Rewrite the patching to use autoPatchelf similar to CLion so that the
RPATH of the binaries are adjusted. While at it also patch all the
binaries in the dotCommon and dotTrace plugins. Those seem to need zlib
and fontconfig which were completely missing before (they are probably
only called when using certain functionality of the IDE).
icu doesn't actually seem to be needed (autoPatchelf does not complain
that it's missing) and the IDE starts fine without it, so drop it for
now.
Most of the libraries listed in the LD_LIBRARY_PATH for the Jetbrains
IDEs are loaded indirectly using JNA in Java code, e.g.
myLibNotify = Native.load("libnotify.so.4", LibNotify.class); [1]
private val library = Native.load("secret-1", SecretLibrary::class.java) [2]
In this case the typical patching mechanism with Nix does not work
because JNA does the library lookup at runtime with its own mechanism.
However, to avoid causing ABI conflicts when using Nix in the terminal
of the IDE it's better to avoid using LD_LIBRARY_PATH. JNA also looks
for a "jna.library.path" Java system property when looking for libraries.
Generate that property with the needed paths instead and append it to
the vmopts file so that the property is applied when starting the IDE.
With this the libraries only become available for the IDE and do not
leak into terminals opened within the IDE context.
[1]: c0a703267a/platform/platform-impl/src/com/intellij/ui/LibNotifyWrapper.java (L40)
[2]: c0a703267a/platform/credential-store/src/linuxSecretLibrary.kt (L38)
Most of the libraries listed in the LD_LIBRARY_PATH for the Jetbrains
IDEs are loaded indirectly using JNA in Java code, e.g.
myLibNotify = Native.load("libnotify.so.4", LibNotify.class); [1]
private val library = Native.load("secret-1", SecretLibrary::class.java) [2]
In this case the typical patching mechanism with Nix does not work
because JNA does the library lookup at runtime with its own mechanism.
However, there is one outlier: stdenv.cc.cc.lib is also added to the
LD_LIBRARY_PATH for libstdc++.so.6 because it is reportedly needed
for some "internals". It does not make sense to access libstdc++
from Java code so it feels like this one was added to work around
some native library or executable that should be patched instead
of using LD_LIBRARY_PATH.
Unfortunately, having libstdc++ in LD_LIBRARY_PATH can also easily
cause ABI conflicts. This is because this variable is inherited into
terminals opened within the IDE. Using a Nix environment there with
different versions of libstdc++ easily causes errors such as
libstdc++.so.6: version `GLIBCXX_3.4.29' not found
Most of the IDEs work just fine without having libstdc++ in
LD_LIBRARY_PATH. Since it's not really clear why it has to be in
there let's just drop it to avoid the ABI conflicts.
[1]: c0a703267a/platform/platform-impl/src/com/intellij/ui/LibNotifyWrapper.java (L40)
[2]: c0a703267a/platform/credential-store/src/linuxSecretLibrary.kt (L38)
* jetbrains.rust-rover: fix darwin install
JetBrains doesn't guarantee that the macOS app will be called
`${product}.app` so I modified the installPhase to copy *.app instead
of ${product}.app, which fails on file does not exist for Rust Rover,
which is `RustRover 2023.2 EAP.app`
I've tested with some other JetBrains apps on darwin aarch64 and they
continue to build as expected.
The nixpkgs documentation mentions how to update out of tree plugins but
one problem is that it requires a nixpkgs clone.
This makes it more convenient.
I've had the need to generate vim plugins and lua overlays for other
projects unrelated to nix and this will make updates easier (aka just
run `nix run nixpkgs#vimPluginsUpdater -- --proc=1` or with the legacy commands:
`nix-shell -p vimPluginsUpdater --run vim-plugins-updater`.
I added an optional "nixpkgs" argument to command line parser, which is the path
towards a nixpkgs checkout. By default the current folder.
update-luarocks-packages: format with black
this isn't complete enough to use as a formal updateScript yet, but
it's definitely an improvement over the current purely-manual process.
Co-authored-by: Robert Helgesson <robert@rycee.net>
Updates rstudio to current version, fixes plotting and enables quarto
and markdown rendering.
Visual mode for markdown editing is still not functional.
* Remove unneeded patch
* Eliminate false quarto version warning
* Fix pandoc and quarto paths
* Adjust patch name to reflect purpose
* Remove panmirror for now
* Update quartoSrc
Co-authored-by: Justin Bedő <cu@cua0.org>
Also contributed: b-rodrigues and kupac
Leaderf is a vim fuzzy finder plugin, for details please see
https://github.com/Yggdroot/LeaderF, and it supports c extension to speed
up 10 times faster; The origin nixpkg does not compile the c extension,
so compile the c extension to make it faster.
1. And also remove the build dir to prevent the unnecessary dependency
on gcc.
2. strip the share lib to keep the files small
Signed-off-by: sheeaza <winsdenny@outlook.com>
The vimrc detection won't work if you are using the vim_configurable package
(which the nixos and home-manager module both do)
because vim-sensible only checks for files in the users home matches `~/...`
but in our case it gets called from a wrapper script which looks something like:
`vim -u /nix/store/.../vimrc`.
