Re: default C versions

[Jason Bacon <jtocino%gmx.com@localhost>]

On 6/30/23 14:40, Greg Troxel wrote:
> David Brownlee <abs%absd.org@localhost> writes:
>
> > If I could ask two random stupid questions? :)
> >
> > Would it be possible to manage this by having GCC_REQD set by default
> > on such a platform, with code to allow "BYPASS_GCC_REQD", so bootstrap
> > could set BYPASS_GCC_REQD to build pkg_tools, and then again to build
> > a useful gcc version? (though rebuilding any gcc dependency later
> > would switch to one built with gcc, which may be... unhelpful)
>
> This is sort of what Jason has done, but slightly different.  It would
> be nice if this were package settable as well, so rebuilds would be
> consistent and it would work on NetBSD which does not bootstrap.   I
> think the way for you to find out if it's possible reasonable is to
> prototype it and see.
>
> Jason's approach means that things in the gcc build path (which is a
> crazy big set) use the base compiler.

What I was envisioning as the next improvement is a tool that lists the
recursive dependencies of the specific gcc package on-the-fly, possibly
using infrastructure we already have, e.g.

NetBSD netbsd9.acadix  bacon ~/Pkgsrc/pkgsrc/lang/gcc9 997: (pkgsrc):
sbmake show-depends-recursive
pkgtools/cwrappers
pkgtools/mktools
pkgtools/digest
sysutils/checkperms
devel/gmake
lang/perl5
devel/m4
devel/libtool-base
devel/pkgconf
devel/libffi
devel/libuuid
devel/readline
lang/python310
textproc/gsed

One of the reasons the dep list is so long is that it's the union of
deps all recent versions of gcc.  If a dep for gcc12 is dropped from gcc
13, it still has to remain in the list, since end-users are free to
choose any supported gcc version.

A tool we could exec to generate the specific list for the gcc version
in use would both simplify mk.conf and avoid exempting unnecessary
packages.  We could either run it during bootstrap and insert the output
in mk.conf in place of the growing historical list, or possibly use it
directly during build, which has the advantage of capturing changes to
gcc deps in the latest updates.

> > Alternatively, would it be feasible to bootstrap twice, once without
> > GCC_REQD just enough to build a gcc package which would install in
> > /usr/pkg-gcc and then a normal bootstrap into /usr/pkg using that as
> > an external compiler?
>
> Probably.  Please prototype and post, and that might be something people
> might want to use.  The real win would be that if we can say "on
> platforms with gcc < X, this is the way" and have pbulk do it too,
> because if it doesn't work in the default pbulk, it doesn't work at all
> from the viewpoint of binary package sets.

I've been tempted to use this approach as well.  While it's extra
overhead, it does keep the main tree simple.