Creating a C/C++ team?

Creating a C/C++ team?

[Greg Hogan]

Guix,

Should we have a C++ team? I think project contributions regarding C
and C++ compilers, libraries, tools, and programs would benefit from a
tag to flag, discuss, and triage issues and a team branch to manage,
test, and pre-build patches.

This team would of course be distinct from the core-packages team,
which manages the most fundamental packages and challenging updates.

Updates to C++ packages often result in a non-trivial number of
dependent package builds, which makes patch review challenging and
leads to overlooked or forgotten contributions and long-delayed
merges. Also, widely used Guix C++ packages are several versions and
many years out-of-date. A C++ team would help us to be more responsive
both to contributors and upstream releases while maintaining a stable
rolling-release and making efficient use of build farm compute and
storage.

Greg

diff --git a/etc/teams.scm b/etc/teams.scm
index fe3291f914..e257650a04 100755
--- a/etc/teams.scm
+++ b/etc/teams.scm
@@ -611,0 +612,14 @@ (define-team zig
+(define-team c++
+  (team 'c++
+        #:name "C/C++ team"
+        #:description
+        "C and C++ compilers, libraries, tools, and programs"
+        #:scope (list "gnu/packages/c.scm"
+                      "gnu/packages/cpp.scm"
+                      "gnu/packages/llvm.scm"
+                      "gnu/packages/llvm-meta.scm"
+                      "gnu/packages/ninja.scm"
+                      "gnu/packages/valgrind.scm"
+                      "gnu/build/cmake-build-system.scm"
+                      "gnu/build-system/cmake.scm")))
+

Re: Creating a C/C++ team?

[Ludovic Courtès]

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> Should we have a C++ team? I think project contributions regarding C
> and C++ compilers, libraries, tools, and programs would benefit from a
> tag to flag, discuss, and triage issues and a team branch to manage,
> test, and pre-build patches.
>
> This team would of course be distinct from the core-packages team,
> which manages the most fundamental packages and challenging updates.

That makes a lot of sense to me.

> Updates to C++ packages often result in a non-trivial number of
> dependent package builds, which makes patch review challenging and
> leads to overlooked or forgotten contributions and long-delayed
> merges. Also, widely used Guix C++ packages are several versions and
> many years out-of-date. A C++ team would help us to be more responsive
> both to contributors and upstream releases while maintaining a stable
> rolling-release and making efficient use of build farm compute and
> storage.

All for it.  I feel bad when you and others contribute tricky C++
package updates and they remain in the patch queue for weeks or months.

(Speaking of which, I hope you also get commit rights soon, which should
help boost this team’s work.)

Thanks for all the work so far and for the exciting perspective!

Ludo’.

Re: Creating a C/C++ team?

[Liliana Marie Prikler]

Hi Greg,

Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:
> Guix,
> 
> Should we have a C++ team? I think project contributions regarding C
> and C++ compilers, libraries, tools, and programs would benefit from
> a tag to flag, discuss, and triage issues and a team branch to
> manage, test, and pre-build patches.
> 
> This team would of course be distinct from the core-packages team,
> which manages the most fundamental packages and challenging updates.
I think there is a risk that this still overlaps with core-packages on
the account of GCC being our main C/C++ toolchain.

Note: while I'm already swamped with work on gnome and emacs, I would
be interested in joining a hypothetical c++ team.

> diff --git a/etc/teams.scm b/etc/teams.scm
> index fe3291f914..e257650a04 100755
> --- a/etc/teams.scm
> +++ b/etc/teams.scm
> @@ -611,0 +612,14 @@ (define-team zig
> +(define-team c++
> +  (team 'c++
> +        #:name "C/C++ team"
> +        #:description
> +        "C and C++ compilers, libraries, tools, and programs"
I would limit the scope to "libraries and tools".  That programs happen
to be written in C/C++ is almost always incidental :)

> +        #:scope (list "gnu/packages/c.scm"
> +                      "gnu/packages/cpp.scm"
Of course.

> +                      "gnu/packages/llvm.scm"
> +                      "gnu/packages/llvm-meta.scm"
Not sure about these two.  Since our main use for LLVM is in
Rust/Zig/Mesa, all of which have their own teams, maybe we should leave
a broader LLVM team with members from all of that open for folks who
are not necessarily interested in the rest of C/C++.

> +                      "gnu/packages/ninja.scm"
> +                      "gnu/packages/valgrind.scm"
If we add these, I would also suggest adding build-tools.scm,
check.scm, debug.scm etc.

> +                      "gnu/build/cmake-build-system.scm"
> +                      "gnu/build-system/cmake.scm")))
These are under guix/ and belong to the core team IIRC.

Cheers

Re: Creating a C/C++ team?

[Ludovic Courtès]

Hi!

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:

[...]

>> This team would of course be distinct from the core-packages team,
>> which manages the most fundamental packages and challenging updates.
> I think there is a risk that this still overlaps with core-packages on
> the account of GCC being our main C/C++ toolchain.
>
> Note: while I'm already swamped with work on gnome and emacs, I would
> be interested in joining a hypothetical c++ team.
>
>> diff --git a/etc/teams.scm b/etc/teams.scm
>> index fe3291f914..e257650a04 100755
>> --- a/etc/teams.scm
>> +++ b/etc/teams.scm
>> @@ -611,0 +612,14 @@ (define-team zig
>> +(define-team c++
>> +  (team 'c++
>> +        #:name "C/C++ team"
>> +        #:description
>> +        "C and C++ compilers, libraries, tools, and programs"
> I would limit the scope to "libraries and tools".  That programs happen
> to be written in C/C++ is almost always incidental :)

Yes, the description could clarify that Greg wrote above, which is that
its scope is disjoint from that of the ‘core-packages’ team.

Ludo’.

Re: Creating a C/C++ team?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

On Fri, Nov 29, 2024 at 10:36:13AM +0100, Liliana Marie Prikler wrote:
> Hi Greg,
> 
> Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:
> > Guix,
> > 
> > Should we have a C++ team? I think project contributions regarding C
> > and C++ compilers, libraries, tools, and programs would benefit from
> > a tag to flag, discuss, and triage issues and a team branch to
> > manage, test, and pre-build patches.
> > 
> > This team would of course be distinct from the core-packages team,
> > which manages the most fundamental packages and challenging updates.
> I think there is a risk that this still overlaps with core-packages on
> the account of GCC being our main C/C++ toolchain.
> 
> Note: while I'm already swamped with work on gnome and emacs, I would
> be interested in joining a hypothetical c++ team.
> 
> > diff --git a/etc/teams.scm b/etc/teams.scm
> > index fe3291f914..e257650a04 100755
> > --- a/etc/teams.scm
> > +++ b/etc/teams.scm
> > @@ -611,0 +612,14 @@ (define-team zig
> > +(define-team c++
> > +  (team 'c++
> > +        #:name "C/C++ team"
> > +        #:description
> > +        "C and C++ compilers, libraries, tools, and programs"
> I would limit the scope to "libraries and tools".  That programs happen
> to be written in C/C++ is almost always incidental :)
> 
> > +        #:scope (list "gnu/packages/c.scm"
> > +                      "gnu/packages/cpp.scm"
> Of course.
> 
> > +                      "gnu/packages/llvm.scm"
> > +                      "gnu/packages/llvm-meta.scm"
> Not sure about these two.  Since our main use for LLVM is in
> Rust/Zig/Mesa, all of which have their own teams, maybe we should leave
> a broader LLVM team with members from all of that open for folks who
> are not necessarily interested in the rest of C/C++.
> 
> > +                      "gnu/packages/ninja.scm"
> > +                      "gnu/packages/valgrind.scm"
> If we add these, I would also suggest adding build-tools.scm,
> check.scm, debug.scm etc.
> 
> > +                      "gnu/build/cmake-build-system.scm"
> > +                      "gnu/build-system/cmake.scm")))
> These are under guix/ and belong to the core team IIRC.

As someone who is in more teams than I mean to be, I wouldn't mind some
overlap between the different teams.  Likely the default llvm hasn't
been upgraded still because no one wants to be the one to break
something.  Also its nice when someone else is able to take something
off your plate.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Creating a C/C++ team?

[Greg Hogan]

On Fri, Nov 29, 2024 at 4:35 AM Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:
>
> Hi Greg,
>
> Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:
> > Guix,
> >
> > Should we have a C++ team? I think project contributions regarding C
> > and C++ compilers, libraries, tools, and programs would benefit from
> > a tag to flag, discuss, and triage issues and a team branch to
> > manage, test, and pre-build patches.
> >
> > This team would of course be distinct from the core-packages team,
> > which manages the most fundamental packages and challenging updates.
> I think there is a risk that this still overlaps with core-packages on
> the account of GCC being our main C/C++ toolchain.

The core-packages team scope includes commencement.scm, gcc.scm, and
gnu-build-system so contributors using etc/teams.scm will be properly
directed. I do share this concern, but I also think there is enough
delay in collecting and building patches on a team branch that someone
would flag a patchset needing core-packages handling and review.

> Note: while I'm already swamped with work on gnome and emacs, I would
> be interested in joining a hypothetical c++ team.

Excellent!

> > diff --git a/etc/teams.scm b/etc/teams.scm
> > index fe3291f914..e257650a04 100755
> > --- a/etc/teams.scm
> > +++ b/etc/teams.scm
> > @@ -611,0 +612,14 @@ (define-team zig
> > +(define-team c++
> > +  (team 'c++
> > +        #:name "C/C++ team"
> > +        #:description
> > +        "C and C++ compilers, libraries, tools, and programs"
> I would limit the scope to "libraries and tools".  That programs happen
> to be written in C/C++ is almost always incidental :)
>
> > +        #:scope (list "gnu/packages/c.scm"
> > +                      "gnu/packages/cpp.scm"
> Of course.
>
> > +                      "gnu/packages/llvm.scm"
> > +                      "gnu/packages/llvm-meta.scm"
> Not sure about these two.  Since our main use for LLVM is in
> Rust/Zig/Mesa, all of which have their own teams, maybe we should leave
> a broader LLVM team with members from all of that open for folks who
> are not necessarily interested in the rest of C/C++.
>
> > +                      "gnu/packages/ninja.scm"
> > +                      "gnu/packages/valgrind.scm"
> If we add these, I would also suggest adding build-tools.scm,
> check.scm, debug.scm etc.
>
> > +                      "gnu/build/cmake-build-system.scm"
> > +                      "gnu/build-system/cmake.scm")))
> These are under guix/ and belong to the core team IIRC.
>
> Cheers

v2 below. Removed compiler (llvm[-meta].scm) scope and removed
"compilers" from description.

+1 to an LLVM team or llvm[-meta].scm in the core-packages scope.

I think cmake-build-system belongs in the C++ team scope. Our use of
cmake is rather simple, even with the enhancements collected in #70031
(which began with a desire to parallelize tests). We should keep cmake
up-to-date without bothering core-packages.

ninja.scm and valgrind.scm are essentially single package modules. The
suggested build-tools.scm, check.scm, and debug.scm are a mix. For
example, check.scm includes python-pytest among other python packages.
Not sure why these are not in python-check.scm unless there would be
circular dependencies. Given the success of the teams workflow, should
we look to divide these mixed modules by team rather than grouping by
theme?

$ ./etc/teams.scm show c++
id: c++
name: C/C++ team
description: C and C++ libraries and tools and the CMake build system.
+ Note that updates to fundamental packages are the competency of the
+ core-packages team.
scope:
+ gnu/build-system/cmake.scm
+ gnu/build/cmake-build-system.scm
+ gnu/packages/c.scm
+ gnu/packages/cmake.scm
+ gnu/packages/cpp.scm
+ gnu/packages/ninja.scm
+ gnu/packages/valgrind.scm

Re: Creating a C/C++ team?

[indieterminacy]

Hello,

Is it too late to have this team having an id name 'cpp' rather than 
'c++'?
As a fan of regex its use of the almighty plus sign has wrankled me.
Also, as an outsider Ive always considered cpp to be representative of 
both C and C++, rather than a subset.

Thanks,

Jonathan

On 2024-12-05 23:35, Greg Hogan wrote:
> On Fri, Nov 29, 2024 at 4:35 AM Liliana Marie Prikler
> 
> ...
> 
> $ ./etc/teams.scm show c++
> id: c++
> name: C/C++ team
> description: C and C++ libraries and tools and the CMake build system.
> + Note that updates to fundamental packages are the competency of the
> + core-packages team.
> scope:
> + gnu/build-system/cmake.scm
> + gnu/build/cmake-build-system.scm
> + gnu/packages/c.scm
> + gnu/packages/cmake.scm
> + gnu/packages/cpp.scm
> + gnu/packages/ninja.scm
> + gnu/packages/valgrind.scm

Re: Creating a C/C++ team?

[Andreas Enge]

Am Fri, Dec 06, 2024 at 08:27:25AM +0000 schrieb indieterminacy:
> Is it too late to have this team having an id name 'cpp' rather than 'c++'?
> As a fan of regex its use of the almighty plus sign has wrankled me.
> Also, as an outsider Ive always considered cpp to be representative of both
> C and C++, rather than a subset.

For me, "cpp" is the "C PreProcessor", and only incidentally the file
suffix for C++ files (and not for C files).

Andreas

Re: Creating a C/C++ team?

[Liliana Marie Prikler]

Am Donnerstag, dem 05.12.2024 um 18:35 -0500 schrieb Greg Hogan:
> v2 below. Removed compiler (llvm[-meta].scm) scope and removed
> "compilers" from description.
> 
> +1 to an LLVM team or llvm[-meta].scm in the core-packages scope.
> 
> I think cmake-build-system belongs in the C++ team scope. Our use of
> cmake is rather simple, even with the enhancements collected in
> #70031 (which began with a desire to parallelize tests). We should
> keep cmake up-to-date without bothering core-packages.
I think we can do smaller topic-branches, regardless of which team
ought to do the review work.  There could even be multiple teams on a
particular series, to push it more quickly.

> ninja.scm and valgrind.scm are essentially single package modules.
> The suggested build-tools.scm, check.scm, and debug.scm are a mix.
> For example, check.scm includes python-pytest among other python
> packages. Not sure why these are not in python-check.scm unless there
> would be circular dependencies. Given the success of the teams
> workflow, should we look to divide these mixed modules by team rather
> than grouping by theme?
In my opinion, we shouldn't be that exclusionary w.r.t. non-C
languages.  Tools being written in Python historically hasn't stopped
C++ users from adopting them – see Meson or Conan for some popular
examples.

> $ ./etc/teams.scm show c++
> id: c++
> name: C/C++ team
> description: C and C++ libraries and tools and the CMake build
> system.
> + Note that updates to fundamental packages are the competency of the
> + core-packages team.
I would just shorten that to "C/C++ libraries and tools", with the
CMake build system being one of said tools :)
Blasting notes into the team description is imho not a good idea.
> scope:
> + gnu/build-system/cmake.scm
> + gnu/build/cmake-build-system.scm
> + gnu/packages/c.scm
> + gnu/packages/cmake.scm
> + gnu/packages/cpp.scm
> + gnu/packages/ninja.scm
> + gnu/packages/valgrind.scm
Scope looks good enough, even while bikeshedding.

Cheers