GNU bug report logs -
#60294
[PATCH] gnu: Add libxapp.
Previous Next
Reported by: "Wamm K. D" <jaft.r <at> outlook.com>
Date: Sat, 24 Dec 2022 07:41:01 UTC
Severity: normal
Tags: patch
Done: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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 <at> 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
This bug report was last modified 2 years and 184 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.