Am Sonntag, den 06.06.2021, 12:14 +0200 schrieb Maxime Devos:
> Leo Prikler schreef op zo 06-06-2021 om 09:39 [+0200]:
> > I think we might want to export a utility procedure
> > (patch-shebangs files inputs)
>
> This procedure already exists, but is undocumented and
> unexported. It is in (gu
Leo Prikler schreef op zo 06-06-2021 om 09:39 [+0200]:
> I think we might want to export a utility procedure
> (patch-shebangs files inputs)
This procedure already exists, but is undocumented and
unexported. It is in (guix build gnu-build-system).
(define* (patch-shebangs #:key inputs outputs
I think we might want to export a utility procedure
(patch-shebangs files inputs)
so that files used during build (e.g. configure, Makefile, etc.) can do
(patch-shebangs build-stuff native-inputs) and the rest implicitly gets
(patch-shebangs files inputs) during the patch-shebangs phase. WDYT?
About <https://issues.guix.gnu.org/47869>
(the ‘wrap-program #:sh’ patch series):
While looking at guix/build/gnu-build-system.scm,
I noticed the 'patch-shebangs' phase, which is run
after the install phase. IIUC, this phase is for
changing shebangs ...
#!/usr/bin/stuff
to ..
s
> should be fixed on core-updates.
Or we could say that it’s not different from other shebangs: it’s up to
the packager to provide all the necessary dependencies.
> 2) we aren’t using wrap-script anywhere. I think a good use case would
> be the Python build system’s “wrap” phase where we
Sorry for the late reply.
Hartmut Goebel writes:
> Am 11.12.19 um 21:25 schrieb Mikhail Kryshen:
>> So the correct way to extend XDG_DATA_DIRS would be
>>
>> export
>> XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:/gnu/store/…-kate-…"
>
> I'm quite confident, adding /usr/shar
tem’s “wrap” phase where we currently use
>> wrap-program. Most of the time we’d be dealing with Python scripts, so
>> using wrap-script would be more appropriate here.
>
> It turns out we are using it in vpnc-scripts.
Yes, that’s where I added it right before writing my email.
--
Ricardo
mong the inputs it will create a bad shebang. This
> should be fixed on core-updates.
I thought the build systems had an implicit guile in them. Looks like I
had that exactly backwards.
>
> 2) we aren’t using wrap-script anywhere. I think a good use case would
> be the Python build sys
Am 11.12.19 um 21:25 schrieb Mikhail Kryshen:
> So the correct way to extend XDG_DATA_DIRS would be
>
> export
> XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:/gnu/store/…-kate-…"
I'm quite confident, adding /usr/share etc. here as default would be
wrong from a guix point of vi
en computing the hash of derivations?
> 2) we aren’t using wrap-script anywhere. I think a good use case would
> be the Python build system’s “wrap” phase where we currently use
> wrap-program. Most of the time we’d be dealing with Python scripts, so
> using wrap-script would be more app
Hartmut Goebel writes:
> Hi,
>
> it came to my mind that currently the qt-build-system wraps the program
> without passing along any environment variables. Thus e.g.
> XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly
> ((guix build utils) wrap-program)
think a good use case would
be the Python build system’s “wrap” phase where we currently use
wrap-program. Most of the time we’d be dealing with Python scripts, so
using wrap-script would be more appropriate here.
What do you think?
--
Ricardo
Hi,
it came to my mind that currently the qt-build-system wraps the program
without passing along any environment variables. Thus e.g.
XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly
((guix build utils) wrap-program) supports prefixing or suffixing an
existing variable
Hartmut Goebel writes:
> Am 02.01.2018 um 20:01 schrieb Ricardo Wurmus:
>> I’ll add a special case for this and a test case.
>
> Great! Thanks.
FYI: I sent an initial implementation to guix-patches and got #29951.
We can further discuss things there.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6
Am 02.01.2018 um 20:01 schrieb Ricardo Wurmus:
> I’ll add a special case for this and a test case.
Great! Thanks.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Hi Hartmut,
> Am 31.12.2017 um 18:27 schrieb Ricardo Wurmus:
>> There’s also a change to the wrap-program procedure that does without
>> the shell wrappers and instead prepends a short Guile program, which is
>> read as a comment in the target language. It’s better to pla
Am 31.12.2017 um 18:27 schrieb Ricardo Wurmus:
> There’s also a change to the wrap-program procedure that does without
> the shell wrappers and instead prepends a short Guile program, which is
> read as a comment in the target language. It’s better to play with this
> in the next
taylanbayi...@gmail.com ("Taylan Ulrich "Bayırlı/Kammer\"") skribis:
> From f7f3ce7140c82380e68ba3299ac17555268b8155 Mon Sep 17 00:00:00 2001
> From: Taylan Ulrich B
> Date: Sat, 29 Nov 2014 13:36:24 +0100
> Subject: [PATCH 1/2] Set Emacs indentation for `wra
===File
/home/tub/media/src/guix/0001-Set-Emacs-indentation-for-wrap-program.patch===
>From f7f3ce7140c82380e68ba3299ac17555268b8155 Mon Sep 17 00:00:00 2001
From: Taylan Ulrich B
Date: Sat, 29 Nov 2014 13:36:24 +0100
Subject: [PATCH 1/2] Set Emacs indentation for `wrap-program'.
Andreas Enge skribis:
> I am only now catching up with the discussion. So far, I do not understand
> why we need a wrapper. Would it not be enough to add the environment variables
> $XDG_DATA_DIRS etc. to the search paths of the programs, in the same way as
> perl or python modules incite the use
Hello,
I am only now catching up with the discussion. So far, I do not understand
why we need a wrapper. Would it not be enough to add the environment variables
$XDG_DATA_DIRS etc. to the search paths of the programs, in the same way as
perl or python modules incite the user to define the correspo
l...@gnu.org (Ludovic Courtès) writes:
> Federico Beffa skribis:
>
>> 1. GSettings schemas: More than schemas compilation, the problem is that
>> the schemas are by default expected to be in $datadir/glib-2.0/schemas
>> (with $datadir usually being /usr/share). In spite of this, other
>> directo
ld be defined in /etc/profile on the
standalone system.
However that would force users to install GTK+ in their profile so that
the modules it comes with are found, right? This would be inconvenient.
> We may just want to check that: (i) paths defined in environment
> variables are not duplic
On Fri, Sep 26, 2014 at 10:09 PM, Federico Beffa wrote:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> This 'wrap-program' strategy of setting environment variables before
>>> running a program has problems. In this ca
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> This 'wrap-program' strategy of setting environment variables before
>> running a program has problems. In this case, it means that every
>> program run within Emacs will inherit that GSETT
Mark H Weaver skribis:
> This 'wrap-program' strategy of setting environment variables before
> running a program has problems. In this case, it means that every
> program run within Emacs will inherit that GSETTINGS_SCHEMA_DIR value.
>
> Along the same lines, I
l...@gnu.org (Ludovic Courtès) writes:
> m...@netris.org skribis:
>
>> When compiling core-updates, I now see the following warning:
>>
>> LC_ALL=C \
>> ./pre-inst-env \
>> /home/mhw/.guix-profile/bin/guild c
Ludovic Courtès writes:
> m...@netris.org skribis:
>
>> When compiling core-updates, I now see the following warning:
>>
>> LC_ALL=C \
>> ./pre-inst-env \
>> /home/mhw/.guix-profile/bin/guild compile -L "."
m...@netris.org skribis:
> When compiling core-updates, I now see the following warning:
>
> LC_ALL=C \
> ./pre-inst-env\
> /home/mhw/.guix-profile/bin/guild compile -L "." -L "." \
> -Wformat -Wun
Eric Bavier writes:
> diff --git a/guix/build/utils.scm b/guix/build/utils.scm
> index d169053..7257b30 100644
> --- a/guix/build/utils.scm
> +++ b/guix/build/utils.scm
> @@ -687,8 +687,7 @@ known as `nuke-refs' in Nixpkgs."
> result
Eric Bavier skribis:
> An updated patch is attached. I changed some of the wording in the
> wrap-program docstring to bring it in a bit more in line with the new
> behavior. Let me know if there should be any more adjustments there. I
> also took the liberty of changing &qu
Ludovic Courtès writes:
> Eric Bavier skribis:
>
>> Currently, if (@ (guix build utils) wrap-program) is called multiple
>> times for the same file, the original file ends up being overwritten.
>
> OK, you’ve convinced me that this improvement is welcome.
An updat
Eric Bavier skribis:
> Currently, if (@ (guix build utils) wrap-program) is called multiple
> times for the same file, the original file ends up being overwritten.
OK, you’ve convinced me that this improvement is welcome.
Some comments on the patch:
Ludovic Courtès writes:
> Eric Bavier skribis:
>
>> Currently, if (@ (guix build utils) wrap-program) is called multiple
>> times for the same file, the original file ends up being overwritten.
>> This happened to me when trying to wrap a python program, which had
>
Eric Bavier skribis:
> Currently, if (@ (guix build utils) wrap-program) is called multiple
> times for the same file, the original file ends up being overwritten.
> This happened to me when trying to wrap a python program, which had
> already once been wrapped by python-build-
Currently, if (@ (guix build utils) wrap-program) is called multiple
times for the same file, the original file ends up being overwritten.
This happened to me when trying to wrap a python program, which had
already once been wrapped by python-build-system. The
python-build-system wrapper sets
36 matches
Mail list logo
