tech-pkg archive

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

Re: First go at adding GCC_VERSIONS_ACCEPTED support

On 21/10/15 00:37, Greg Troxel wrote:
David Sainty <> 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.

I think that's ok :)  So long as the defaults avoid risk.

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

I agree, and I think bloat is the least important concern too. But still a 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


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.

Sounds good.

Home | Main Index | Thread Index | Old Index