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
> actually installed
> 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
>
> I don't think this is too bad an approach, but there probably is room
> for improvement:
>
> - It's probably a bit wasteful to check if a version exists only to
> pass this on to the following bits in the makefile which must re-check
> once again (somewhere).
> - I've assumed versions would be listed as "4.7 4.8 4.9", etc. There
> is no error handling. It probably won't work if someone puts "4.8.4"
> for instance, nor if they put "47 48 49". I'm not sure how much error
> handling is required?
I'm glad to see someone working on this.
* I wonder if there is a similar issue with clang, and if we should be
thinking about how this would be extended. (I don't mean to say
changes that don't address clang should be rejected.) It may be that
clang isn't yet old enough to accumulate these sorts of
works-for-x-not-y issues.
* 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.
* New versions keep appearing. It's at best awkward to have to go edit
packages to say the new version is ok, and in practice it isn't going
to happen.
* Generally, packages are going to need a versions which is >= X, for
some X, because they depend on features that appeared in X.
Additionally, there may be some versions that aren't ok, for various
reasons. So I think what we want to express is ">= X, but not Y or
Z", in general.
* 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)
GCC_VERIONS_INCOMPATIBLE = (list of versions > MIN that are not ok for
some reason)
We could either issue a deprecation warning for GCC_REQD, or we could
reuse that variable - since mostly it is expressing a minimum - and only
warn if it's a list instead of a single version. That could lead us to:
GCC_REQD = (lowest versions that is ok, must be just one)
GCC_INCOMPATIBLE = (list of vesrions > REQD that are not ok)
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.
One thing to keep in mind is that in theory, variables in pkgsrc are
either for the user to set in mk.conf, for packages to set in Makefiles,
or internal for mk/* to set, and we don't want to have variables that
are set in multiple of those places.
Note that there are regexps for matcing things that are like 4.7. I'm
not sure this is good; it may be better to error out if a version is
listed that's not in gcc.mk as one of the set of possible versions.
Attachment:
pgpOwcQ1MhoH5.pgp
Description: PGP signature