On Fri, Nov 29, 2024 at 4:35 AM Liliana Marie Prikler <liliana.prik...@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
