Re: First go at adding GCC_VERSIONS_ACCEPTED support

[David Sainty <david.sainty%gmail.com@localhost>]

On 02/10/15 11:45, Greg Troxel wrote:
> atomicules <base%atomicules.co.uk@localhost> writes:
>
> > I'm still happy to carry on having a go at implementing whatever is
> > needed. But I'm not sure what the consensus is on the approach
> > required?

Cool :)

> > Do we still want a list of incompatible versions? And a
> > PKGSRC_GCC_MIN?
> Not sure about consensus, but:
>
> I would like the version variable for each package to be a single min
> version, and eventually also support antoher variable with incompatible
> versions.  However, it's not clear that greater-and-incompat exists all
> that often in reality, so defining that in the docs with a
> not-implemented-yet note seems fine.
>
> I have mixed opinions about picking an installed acceptable vs
> deterministic choosing.  I tend to go with deterministic and let people
> give a min if they want, since deterministic is good.  Perhaps we should
> set a min with ?=, so that the normal case is not problematic.

I think deterministic is good too.  It's certainly the safer approach.

> PKGSRC_GCC_MIN also seems like a good idea.   I would use it to say
>    "any time we are building with gcc, use at least PKGSRC_GCC_MIN".
> Another approach is
>    "any time we are building with gcc and base isn't good enough, use at
>    least PKGSRC_GCC_MIN".
> and really if we end up with PKGSRC_GCC_MIN and PKGSRC_GCC_FORCE that
> would be fine.  I don't think we really know why we need those exactly
> and thus it's hard to figure out.
My experience is that the second (less aggressive) approach works pretty 
well.

The former approach might ultimately be simpler, but it seems quite a 
heavy-weight solution.  It might already be supported by 
USE_PKGSRC_GCC=yes + GCC_REQD in mk.conf, by the way.

It might be the right approach for any package providing a C++ API 
though (not particularly easy to automatically determine at pre-build time).

> The really tricky part is the notion of inheriting versions from other
> packages that a package depends on.  I see the point, but it opens up
> many cans of worms, so I would be inclined to skip this for now, and to
> have a different mechanism (really, different variable to set in bl3)
> when it is time to do that part.  In general, I think if we can solve
> part of the problem and leave the rest for later without incurring
> significantly more pain because of the split, doing half is a win.

I'm not too concerned about the approach taken here, but I tend to think 
GCC_REQD mostly solves this, so it's not clear to me whether it needs to 
be reinvented.

I certainly don't mind it being reinvented if it provides some definable 
gain though :)

> I definitely would like to see diffs to mk/compiler/gcc.mk fixing up the
> specs for variables and documenting the new behavior, even before code.
> Writing really clear text will help clarify the difficult details.

I'll give GCC_REQD a go, to see if it helps the discussion:

Old:

# GCC_REQD
#       The minimum version of the GNU Compiler Collection that is
#       required to build this package. Setting this variable doesn't
#       change the compiler that is used for building packages. See
#       ONLY_FOR_COMPILER for that purpose. This is a list of version
#       numbers, of which the maximum version is the definitive one.
#
#       This variable can also be set by the user when USE_PKGSRC_GCC
#       is in effect to ensure that a specific compiler is used for
#       packages which do not specify a higher version.
#

New:

GCC_REQD

A list of values specifying the minimum version of the GNU Compiler 
Collection that is required to build this package.  The list is 
constructed from version numbers appended by this package and by any 
included buildlink3.mk files.  Each package or buildlink3.mk file will 
generally append at most a single version number to GCC_REQD; forming a 
list of version numbers of which the maximum version is the definitive one.

Setting this variable doesn't change the compiler that is used for 
building packages. See ONLY_FOR_COMPILER for that purpose.

This variable can also be set by the user when USE_PKGSRC_GCC is in 
effect to ensure that a specific compiler is used for packages which do 
not specify a higher version.