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.
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.