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 28/09/15 14:54, Greg Troxel wrote:
David Sainty <david.sainty%gmail.com@localhost> writes:
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.
The real question is to what extent the compilers are ABI compatible, or
not. It seems generally they are. But then there's using e.g
gcc49-libs. I am curious if you think the no-mixing rule is only about
packages that use gccXY-libs, or if it's more general.
I think gccXY-libs is perhaps the primary source of pain. I'm not
totally sure I've seen anything that didn't boil down to that.
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.
Do you mean wrong semantics, or a confusing name, or ?
Both :)
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 order.
That's also a good point.
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.
That almost feels like picking gcc/clang at bootstrap time, and could
lead to using gcc48 to build everything because some packages need 4.8.
It seems nonobvious if that's a good plan.
Locally I have used a very specific hack for some time (I'll paste it to
the bottom) that implements this behaviour for GCC 4.8.
The consequence is that the native compiler gets used normally (which
varies depending on the machine), but any package asking for a specific
compiler above native uses GCC 4.8.
That isn't too painful. E.g. on a machine with native GCC 4.6, I only
see the below dependencies on GCC 4.8. Actually, for that machine it
probably hasn't really changed matters at all.
Information for gcc48-4.8.4:
Required by:
webkit24-gtk-2.4.9nb1
epiphany-2.30.6nb42
webkit24-gtk3-2.4.9
Here's a machine with native GCC 4.4 and nearly the same set of packages
installed:
Information for gcc48-4.8.4:
Required by:
boost-jam-1.59.0
boost-headers-1.59.0
boost-libs-1.59.0
librevenge-0.0.2nb2
libwpd-0.10.0nb1
libwpg-0.3.0nb2
libcdr-0.1.1nb3
libvisio-0.1.3nb1
webkit24-gtk-2.4.9nb1
libftdi1-1.1nb3
inkscape-0.91nb6
epiphany-2.30.6nb42
webkit24-gtk3-2.4.9
So, I know at least inkscape would normally pull in GCC 4.5 as well.
This way I've avoided having to build at least one more GCC.
But, still, the list of packages depending on gcc48 isn't too onerous.
I think that much isn't a terrible plan, the list isn't any longer than
the total list would be if I had two, three or four gcc versions installed.
I agree it's not obviously a good plan to extend that to the extreme of
building absolutely every package with gcc48. But ... some days I wonder :)
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?
The problem I have with GCC_REQD is that it tends to be set to one
value, and is documented to take a list, and there isn't an easy way to
express that anything >= X is ok, except for a few values, so it will
often be out of date or not really expressive enough.
Yes, it is a list (as far as gcc.mk is concerned), but in any one
package would normally be one value. But across all dependencies it
could be a longer list.
The semantics are Anything >= max(GCC_REQD). But the definition of
Anything is, I think, what has led to this discussion :)
One could argue
that almost no packages need to exclude versions above the min, but it
often seems that too old lacks features and too new throws errors.
I haven't seen this case in an instance where, as a workaround, there
wasn't an even newer GCC that could be used as the new minimum (or a
newer package distribution that worked with the newer GCC). But if this
case is important to handle without workarounds, GCC_REQD is
insufficiently general...
You said in another email:
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)
Yes, so I see your motivation... That would support your case.
But GCC_REQD does need to be a list, because there may be a
GCC_REQD+=4.5 in the current package, and another GCC_REQD+=4.8 in a
buildlink somewhere.
Your notion of the user giving a version to jump to beyond the system
version sounds sensible, to avoid the mixing issue (both from failures
and the pain of building many versions).
Yes, I just got sick of having multiple GCCs when just one would do :)
Mixing has only otherwise been a problem when Pkgsrc has had a
GCC_REQD-related bug.
--- mk/compiler/gcc.mk.orig 2015-06-04 16:27:43.859607152 +1200
+++ mk/compiler/gcc.mk 2015-06-12 14:56:34.095516042 +1200
@@ -385,85 +385,7 @@
_USE_GCC_SHLIB?= yes
. endif
. endif
-.elif !empty(_NEED_GCC44:M[yY][eE][sS])
-#
-# We require gcc-4.4.x in the lang/gcc44 directory.
-#
-_GCC_PKGBASE= gcc44
-. if !empty(PKGPATH:Mlang/gcc44)
-_IGNORE_GCC= yes
-MAKEFLAGS+= _IGNORE_GCC=yes
-. endif
-. if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
-_GCC_PKGSRCDIR= ../../lang/gcc44
-_GCC_DEPENDENCY= gcc44>=${_GCC_REQD}:../../lang/gcc44
-. if !empty(_LANGUAGES.gcc:Mc++) || \
- !empty(_LANGUAGES.gcc:Mfortran) || \
- !empty(_LANGUAGES.gcc:Mfortran77) || \
- !empty(_LANGUAGES.gcc:Mobjc)
-_USE_GCC_SHLIB?= yes
-. endif
-. endif
-.elif !empty(_NEED_GCC45:M[yY][eE][sS])
-#
-# We require gcc-4.5.x in the lang/gcc45 directory.
-#
-_GCC_PKGBASE= gcc45
-. if !empty(PKGPATH:Mlang/gcc45)
-_IGNORE_GCC= yes
-MAKEFLAGS+= _IGNORE_GCC=yes
-. endif
-. if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
-_GCC_PKGSRCDIR= ../../lang/gcc45
-_GCC_DEPENDENCY= gcc45>=${_GCC_REQD}:../../lang/gcc45
-. if !empty(_LANGUAGES.gcc:Mc++) || \
- !empty(_LANGUAGES.gcc:Mfortran) || \
- !empty(_LANGUAGES.gcc:Mfortran77) || \
- !empty(_LANGUAGES.gcc:Mobjc)
-_USE_GCC_SHLIB?= yes
-. endif
-. endif
-.elif !empty(_NEED_GCC46:M[yY][eE][sS])
-#
-# We require gcc-4.6.x in the lang/gcc46 directory.
-#
-_GCC_PKGBASE= gcc46
-. if !empty(PKGPATH:Mlang/gcc46)
-_IGNORE_GCC= yes
-MAKEFLAGS+= _IGNORE_GCC=yes
-. endif
-. if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
-_GCC_PKGSRCDIR= ../../lang/gcc46
-_GCC_DEPENDENCY= gcc46>=${_GCC_REQD}:../../lang/gcc46
-. if !empty(_LANGUAGES.gcc:Mc++) || \
- !empty(_LANGUAGES.gcc:Mfortran) || \
- !empty(_LANGUAGES.gcc:Mfortran77) || \
- !empty(_LANGUAGES.gcc:Mobjc)
-_USE_GCC_SHLIB?= yes
-. endif
-. endif
-.elif !empty(_NEED_GCC47:M[yY][eE][sS])
-#
-# We require gcc-4.7.x in the lang/gcc47 directory.
-#
-_GCC_PKGBASE= gcc47
-. if !empty(PKGPATH:Mlang/gcc47)
-_IGNORE_GCC= yes
-MAKEFLAGS+= _IGNORE_GCC=yes
-. endif
-. if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
-_GCC_PKGSRCDIR= ../../lang/gcc47
-_GCC_DEPENDENCY= gcc47>=${_GCC_REQD}:../../lang/gcc47
-. if !empty(_LANGUAGES.gcc:Mc++) || \
- !empty(_LANGUAGES.gcc:Mfortran) || \
- !empty(_LANGUAGES.gcc:Mfortran77) || \
- !empty(_LANGUAGES.gcc:Mgo) || \
- !empty(_LANGUAGES.gcc:Mobjc) || \
- !empty(_LANGUAGES.gcc:Mobj-c++)
-_USE_GCC_SHLIB?= yes
-. endif
-. endif
-.elif !empty(_NEED_GCC48:M[yY][eE][sS])
+.elif !empty(_NEED_GCC44:M[yY][eE][sS]) ||
!empty(_NEED_GCC45:M[yY][eE][sS]) || !empty(_NEED_GCC46:M[yY][eE][sS])
|| !empty(_NEED_GCC47:M[yY][eE][sS]) || !empty(_NEED_GCC48:M[yY][eE][sS])
#
# We require gcc-4.8.x in the lang/gcc48 directory.
#
Home |
Main Index |
Thread Index |
Old Index