[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: First go at adding GCC_VERSIONS_ACCEPTED support
On 26/09/15 03:14, Greg Troxel wrote:
atomicules <base%atomicules.co.uk@localhost> writes:
What I've done is, just before the bit where the GCC_REQD list gets
worked down to a single, highest _GCC_REQD value, is:
1. Look for the presence of GCC_VERSIONS_ACCEPTED.
2. If it is there, check each version in the list against what is
3. Once it finds a match it sets GCC_REQD to that single value (so it
picks the first found)
4. If it finds no matches then set GCC_REQD to GCC_VERSIONS_ACCEPTED
* GCC_REQD and GCC_VERSIONS_ACCEPTED are trying to say more or less the
same thing. So while it's probably best not to try to change it all
at once, I'd like to head to a single mechanism for a package to
express which versions are ok, deprecate the old ones, and convert
packages to that.
Whatever the approach, it needs to work with merging requirements from
E.g. If you are installing X, which likes GCC 4.5 and up, but it
buildlinks in Y which adds a requirement for GCC 4.8 and up, then the
final selection has to be GCC 4.8 and up.
Looking for a match in GCC_VERSIONS_ACCEPTED doesn't seem to cope with
that? If it had a list that said "4.5 4.8", it would happily
(erroneously) choose 4.5, I take it?
Note that prior art in Pkgsrc for *_ACCEPTED variables is (universally?)
different to GCC. For Apache, PHP, Emacs, Python the decision for which
package is to be used has already been made. The package is indicating
whether it is compatible with that decision. The result is either "Ok",
With GCC the package is participating in choosing which GCC to use - the
decision hasn't been made yet, and will be made based on the information
from multiple packages (current + buildlinked packages). The result
will normally never be "Fail", it'll be an agreed best option out of
"native", "gcc45", "gcc48", etc...
That could suggest that *_ACCEPTED is the wrong pattern to use for GCC.
* Obviously the base system gcc should be used if it's ok. And if not,
then there's the question of which one to pick to install, among the
acceptable versions. This feels like it should perhaps be a user
pref, or perhaps pkgsrc should have this hard-coded for now, perhaps
picking 4.8 if that's acceptable, else the lowest acceptable version,
or something like that. Or perhaps just the simplest thing and
install the minimum acceptable version.
All of this leads me to want to have two variables:
GCC_VERSION_MIN = (lowest version that is ok for this package)
That might work if it's a list. But, actually, that's pretty much what
Your patch could certainly introduce private variables within gcc.mk
(often with a _ prefix); there's nothing magic about setting GCC_REQD
and not touching existing code. This approach would have the side
effect of causing most packages with GCC_REQD=4.5, for example, to be ok
with a 4.8 compiler. This is actually what's documented already in
mk/compiler/gcc.mk, but it seems that it doesn't do it.
I'm pretty sure that's broadly what gcc.mk is trying to do.
I think what it doesn't do is take note that if the native compiler is
4.4, the package needs 4.5, and gcc48 happens to be installed then it
could use gcc48 - it'll install gcc45 instead. Is that what you have in
On the other hand, having it use gcc48 automatically if it's installed
is not great for repeatability of builds. There's an argument to be
made there that it shouldn't use gcc48 just because it happens to be
there, because you'll start to experience different package results on
the same machine with the same configuration depending on package build
What would be nice is being able to explicitly set something like
PKGSRC_GCC_MIN in /etc/mk.conf to 4.8, to tell Pkgsrc that if it's going
to install a GCC package (I.e. native compiler isn't enough) then jump
straight up to 4.8.
In fact, if a user-mk.conf-settable PKGSRC_GCC_MIN was supported, and
GCC_REQD was left as it is, I think all my personal use cases would be
satisfied :) Is there a compelling use case for something more complicated?
Main Index |
Thread Index |