guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#60294] [PATCH] gnu: Add libxapp.


From: Liliana Marie Prikler
Subject: [bug#60294] [PATCH] gnu: Add libxapp.
Date: Sat, 24 Dec 2022 15:13:41 +0100
User-agent: Evolution 3.46.0

Am Samstag, dem 24.12.2022 um 11:23 +0000 schrieb Jaft:
>  On Saturday, December 24, 2022 at 04:36:02 AM CST, Liliana Marie
> Prikler <liliana.prikler@gmail.com> wrote: 
> 
> Am Samstag, dem 24.12.2022 um 01:30 -0600 schrieb Wamm K. D:
> > > +              (substitute* "pygobject/meson.build"
> > > +                (("get_option[(]'py-overrides-dir'[)]")
> > > +                 (string-append "'"
> > > +                                (assoc-ref outputs "out")
> > > +                                "/lib/python"
> > > +                                #$(version-major+minor (package-
> > > version python))
> > > +                                "/site-
> > > packages/gi/overrides'")))
> > I think python-build-system has a function to get this version in a
> > more reliable way.
> 
> Would you possibly know any more details on it? Just looking through
> the module, I don't see any functions regarding version number, I'm
> afraid, and it's not intuitive to me how I might use it in this
> context if I'm using a different build system for the package.

You're looking for the (site-packages) function.  As for how to use it,
you need to "mix in" the python build system as is done for instance in
python-gst.

> > > +                (("'/usr/bin/pastebin'") (string-append "'"
> > > +                                                        (assoc-
> > > ref
> > > outputs "out")
> > > +                                                       
> > > "/bin/pastebin'"))
> > Oof, fine, but note that you can also write #$output
> 
> Fair; I'd thought about it but the example I was working off of was
> using G-expressions and did it this way so I just went with it.
> 
> Something I've wondered: is there a point to having the lambda
> arguments be "#:key outputs", if you can just use "#$output"? I've
> seen a few setup their lambda that way only to use "#$output" and not
> ever use "outputs".
> 
> I may just be missing something regarding G-expressions, though.
The outputs key comes from a time in which #$output could not yet be
used in phases.  There is currently no definitely preferred flavour.

> > > +    (synopsis "Cross-desktop libraries and common resources for
> > > X-
> > > apps")
> > > +    (description
> > > +     "The components which are common to multiple GTK desktop
> > > environments
> > > +(Cinnamon, MATE and Xfce) and required to implement cross-DE
> > > solutions.")
> > The description should consist of full sentences.
> > Also, since X-Apps are quite specific to Linux Mint, you should
> > probably not take folks knowing what they are for granted.
> 
> True but is there any easy way to specify what they're related to
> without making it much longer than just a synopsis?
> 
> "Cross-desktop libraries and common resources" can apply to many
> things and is generic to the point of being unhelpful, I'd think.
> 
> I could always do "developed by Linux Mint" instead of "for X-apps"
> which might be more familiar but, again, it borders to being
> unhelpfully unspecific, again (even if less so), to me; there are
> probably a lot of "Cross-desktop libraries and common resources"
> developed by Linux Mint. This particular library was developed for
> use with the X-apps they're developing, specifically.
> 
> I'm just not sure what other description would work while still being
> a synopsis.
I think "Library for traditional GTK applications" would work fine,
looking at [1].

> > 
Cheers

[1]
https://linuxmint-developer-guide.readthedocs.io/en/latest/xapps.html





reply via email to

[Prev in Thread] Current Thread [Next in Thread]