[bug#70282] [PATCH v4] gnu: gnome-shell: Wrap screencast service.

[Dariqq <dariqq@posteo.net>]

On 10.05.24 18:04, Liliana Marie Prikler wrote:
> Am Freitag, dem 10.05.2024 um 14:59 +0000 schrieb Dariqq:
>> Hi Liliana and Maxim,
>>
>> On 09.05.24 00:11, Liliana Marie Prikler wrote:
>>> Hi Dariqq,
>>>
>>> Am Mittwoch, dem 08.05.2024 um 21:18 +0000 schrieb Dariqq:
>>>> [...]
>>>>
>>>> On 08.05.24 21:51, Maxim Cournoyer wrote:
>>>>
>>>>> [...]
>>>>> Perhaps a simple patch would convey the change better and be
>>>>> easier
>>>>> to
>>>>> maintain in the future / be readily available for other
>>>>> distributions to
>>>>> use.
>>>>
>>>> The simple patch that would do this is basically the patch from
>>>> nixos
>>>> in  v1 of this which adds a shebang line for gjs to the service
>>>> invocation files (rather than the dbus service invoking $gjs
>>>> $service). The problem then is that wrap-program changes the
>>>> filename
>>>> to * .real which makes gjs unhappy.
>>>>
>>>> [...]
>>>> Maybe another comment, similiar to the one Liliana suggested
>>>> earlier
>>>> in this thread, could be added at the beginning to inform about
>>>> changing to wrap script + patch instead once that is a viable
>>>> option?
>>> The pattern we typically use is to add an autotools-style
>>> "variable",
>>> e.g. @GNOME_SHELL_GST_PLUGIN_SYSTEM_PATH@ through a patch, then use
>>> substitute* to fill it in.  I don't think it's a requirement, but
>>> since
>>> Maxim suggested, it'd definitely be nice to have.
>>>
>>
>> Tried this today and as the js service files are created from a
>> common template using mesons 'configure_file' method this sets all
>> autotools-style variables unknown to meson to the empty string.
>> Afterwardes the susbtitute* at the wrapping phase is unable to
>> replace anything ofc.
>>
>> So I think I would need to either change the naming-scheme of the
>> placeholders or substitute them into the template file  before the
>> files get configured by meson.
> Or you add an option to meson_options.txt to fill it in, so that you
> can provide the right value via #:configure-flags

I'd want to avoid putting the environement variables together myself and 
rather use getenv to retrieve the value at build time though. Don't 
think that would work with #:configure-flags

> 
> Cheers

Have a nice day