tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: default C versions

On 6/30/23 14:40, Greg Troxel wrote:
David Brownlee <> 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

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.

Home | Main Index | Thread Index | Old Index