[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