Re: Creating a C/C++ team?

[Greg Hogan <code@greghogan.com>]

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