Hi,
Am Samstag, dem 05.02.2022 um 13:52 -0500 schrieb Leo Famulari:
> On Sat, Feb 05, 2022 at 08:22:32AM +0100, Liliana Marie Prikler
> wrote:
> > Looking at the size of this thing compared to our audacity, I
> > thought to myself "hmm, that's a shell script" and sure enough
> >
> > --8<---------------cut here---------------start------------->8---
> > #!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-
> > 5.1.8/bin/sh
> >
> > lib="${0%/*}/lib/audacity"
> > share="${0%/*}/share/audacity"
> >
> > export LD_LIBRARY_PATH="${lib}:${LD_LIBRARY_PATH}"
> > export
> > AUDACITY_MODULES_PATH="${AUDACITY_MODULES_PATH}:${lib}/modules"
> > export AUDACITY_PATH="${AUDACITY_PATH}:${share}"
> >
> > exec "${0%/*}/bin/audacity" "$@"
> > --8<---------------cut here---------------end--------------->8---
>
> Interesting...
>
> > At the time of writing none of these appear particularly needed,
> > though
> > if the time comes we might just port over the 'wrap-emacs-paths
> > phase.
>
> I figure it's there for a reason. Maybe we just need to make sure it
> ends up in 'bin/'? But, it's weird that the build scripts create
> multiple executables with the same name in these different
> directories.
I don't think it should be in bin/. Looking at the script, it appears
to be written for the install root, which... eh...
> > We can try searching for the bits in CMakeLists that install this
> > wrapper or we can simply drop the file. WDYT?
>
> I don't know... I wonder if Audacity is worse for Guix users since
> this shell script doesn't end up in $PATH.
Concerning LD_LIBRARY_PATH, that probably has no effect on Guix users.
AUDACITY_MODULES_PATH and AUDACITY_PATH could bug them, but only if run
through the store – I already added search-path specifications for
them. The question therefore really is whether to extend our wrapper or
not.
1. Cheers
