David Sainty <david.sainty%gmail.com@localhost> writes: >> Then, we shouldn't need GCC_REQD in C++ packages, and we can use the >> min/objectioable scheme in C, since we can mix? > > I've thought about this approach a few times too. Probably allowing > the user to override it addresses my minor concern that it might force > some users to build a GCC on very purpose-specific systems where they > may prefer not to. That can be ok, but this either gets hairy or unsound. > GCC_REQD is sometimes used to avoid GCC bugs present in a range of > versions, not just to ensure certain features are present. I think in > principle that a package should be able to state an explicit GCC > minimum, as well as relying on the default USE_LANGUAGES handling. That is leading me to want the basic mechanism (new enough for defined features) to be separate from the exception mechanism. > Assuming that we default to, say, GCC 4.9 for C++ - I think that means > for most people PKGSRC_GCC_MIN should be 4.9 for C packages too. > I.e. if we're expecting to build GCC 4.9 as soon as we hit a C++ > package, maybe the default preference should be to use that version > for C packages too, if and only if the native version isn't good > enough for some package or other. This seems to be a tension between repeatable builds, bloat and concern about mixing versions. I think repeatable builds should be a key concern. So I would like to see each USE_LANGUAGES name define clearly (in a comment) what it means, and to have a specified gcc version to meet those requirements, and use it. That can lead to C and C++ being different, and we can either avoid that now or later, if we have real evidence of problems. So that could lead to PKGSRC_GCC_MIN= 4.5 PKGSRC_GXX_MIN= 4.8 with the expectation that this results in using the system version if >= and otherwise requires exactly that version built from pkgsrc. With perhaps the extra logic that if the base system does not satisfy PKGSRC_GCC_MIN, then build/require PKGSRC_GXX_MIN. If it turns out to be a bad to mix, we can just set them equal. For C, MIN might end up being a version with atomics, as I've seen packages not build with 4.1 and build with 4.5. I'm unclear how that interacts with standards. Or perhaps those get handled with GCC_REQD, and that logic will pick PKGSRC_GXX_MIN if it's good enough. For GCC_REQD, I am hoping that the number of instances will be very small, and we could perhaps just let it be until we get a handle on how much is needed. > If there isn't a compelling reason to choose 4.9, I suggest 4.8 > instead as a default. Grep says that nothing in Pkgsrc explicitly > requires beyond 4.8 - though there are several that call for 4.8 as a > minimum. GCC 4.8 is the current default native for Ubuntu and related > long term support installations, so we will support at least those > users a bit better if we don't force a 4.9 build on them. I agree, partly because NetBSD 7 has 4.8. Aside from introduction of new features like C++11 support, it would seem broken of gcc if any non-broken package demanded a higher version. There are always going to be issues, and it's a question of spreading the pain. All in all, I think the first step is to force >= 4.8 for C++ builds.
Attachment:
signature.asc
Description: PGP signature