David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > > > ... but you need selection logic to pick the compiler to build gcc > > > with. > > > > So far it is "use the base compiler pointed to by PKGSRC_COMPILER" with > > the implication of "if your system's compiler can't build gcc5, you are > > out of luck". > > That most likely unsupports all the junkyard platforms; then again, > most of those probably can't run a modern C++ compiler anyway and > shouldn't try. So they should just default to not building a compiler > from pkgsrc. I don't see why you say "that most likely" vs "on such systems things already don't work". If a system can't build gcc5 from pkgsrc, it's not reasonable to set PKGSRC_GXX_VERSION to 5. So there's no "unsupporting", just incurring build time sometimes unnecessarily in order to have simplicity, while making many more things buildable, > But it seems like there should be some support for bootstrapping in > this situation... I don't follow. If you can't build a compiler at all, then it doesn't make sense to talk about to arrange a clean bootstrap. > > The alternative is not so bad. The choice is basically: > > > > do you want to be able to build things in C++ (or maybe C++11 or > > higher)? If so, take the pain of building gcc5 and use it for > > everything. > > > > If not, just use the base compiler > > > > That's not quite right, but I think it's operationally pretty close. > > There's another issue: you still have to recompile everything when you > change the compiler you built from pkgsrc. Yes - I meant you make one choice, and then you get one of two outcomes, with no switching plans without starting over. > But even then since there are basically only two choices when you go > to compile something (build the recommended compiler from pkgsrc, or > don't), and since once you've built a compiler from pkgsrc there's no > substantive downside to using it for everything, we can do the > following: That's true; hence why it would be default to gcc5 normally. > - when you go to build a package, check the compiler versions of > everything it depends on. (That is, check the actual packages, not the > bl3 files, by repeated or recursive pkg_info invocations.) > - if these aren't all the same and/or don't match the currently > selected compiler, fail and print the list of packages that need to be > rebuilt. > > Doing this in addition to the proposed scheme for deciding what the > currently selected compiler is will add a layer of safety. I don't think lack of this should block progress, but if you want to implement it that sounds fine. Right now it should be optional, since we do this all the time with how GCC_REQD works. > And it's making me think there should be a master USE_BUILTIN_GCC > switch (or something like that) so you can do "make USE_BUILTIN_GCC=yes". That would be fine; we already will more or less have that to exempt packages needed to build the new gcc from being required to use it. > (And it would be nice to unify this logic with builtin package > handling, but that isn't going to happen anytime soon.) Maybe, but it seems different enough that I don't see the unification benefit. But I'll read your patch :-) > > My impression is that almost all people with systems with gcc <= 4.8 > > would rather build a new version than have the current situation of many > > things not building. > > How hard is it currently to do that explicitly? I've never tried... It's not super hard. Basically, start with nothing, build gcc5, and then put GCC_REQD=5 in mk.conf. Jason Bacon has been doing this, more or less, on Centos/RHEL, but with exempting gcc and deps from the logic. Really we are just talking about formalizing what Jason has already posted (to get functionality on a lot of systems that are troubled now) changing the notion the of what GCC_REQD means from "use a different compiler" to "if the chosen compiler is not >= the needed one, fail" (to get safety, compared to the C++ ABI mixing we have now)
Attachment:
signature.asc
Description: PGP signature