[bug#71897] [PATCH 3/5] gnu: Add cppgir-for-telegram-desktop.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Dan,

dan <i@dan.games> writes:

> On 7/9/2024 10:25 AM, Maxim Cournoyer wrote:
>> Hi Dan,
>> dan <i@dan.games> writes:
>> 
>>> * gnu/packages/telegram.scm (cppgir-for-telegram-desktop): New variable.

[...]

>> That'd be reasonable as a new package if it was very tightly
>> developed
>> with telegram, but it doesn't seem to be the case.  I'd prefer having it
>> in (gnu packages glib).
>> What is the "compilation error" you had mentioned when using version
>> 2.0?  Does the cppgir release fails to compile itself, or is it
>> telegram that then doesn't build using that one?
>
> Sorry about not directly replying the previous message.  It's the
> latter, telegram-desktop fails to compile with cppgir@2.0.
>
>> If the later, I'd define, in (gnu packages glib)
>> --8<---------------cut here---------------start------------->8---
>> (define-public cppgir
>>   [...]
>>   "original package at version 2.0")
>> (define-public cppgir-for-telegram-desktop
>>   (package
>>    (inherit cppgir)
>>    (source ... (using latest or telegram-specific (?) commit))))
>> --8<---------------cut here---------------end--------------->8---
>
> For the lower package definition, I put it in (gnu packages glib) or
> (gnu packages telegram)?  I think it should be the latter one?

It's a bit counter-intuitive, but it has to be in the former, to avoid
cyclic module dependencies caused by top level variables referring one
another in different modules (that's fine for delayed fields, but the
inherit field is not delayed).  For more information on this topic, see
(info 'guix (Cyclic Module Dependencies)').

>> Sorry for the back and forth, we're narrowing down on the perfect
>> submission; keep it up.  Don't forget to use -v5 for your next patches
>> submission :-), and ensure 'guix lint' is happy with all the packages.
>> Thank you for your efforts!  Keep it up.
>> 
>
> Sorry about forgetting to add revision number to the patch
> series. Although we have mumi right now, there are still a bit of
> manual works to be done before sending patches.  I constantly forget
> some of them.

I do like the ability of patman of recording where my submission
metadata as git trailers in the top commit.  Mumi could in theory avoid
the need for automatically using -v though, since it can look at the
past messages sent to an issue and could infer which revision should be
used, in theory.

-- 
Thanks,
Maxim