Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/12/2012 05:00, matt wrote:
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of
USE_GCC=any to a port's Makefile, and then committed that change to
various ports. In most (but not all!) cases this will tell the port
build with gcc instead of clang (*) .
Why not USE_GCC ?= any for the poor guys like me who build (some)
ports with
USE_GCC=4.6 ?
For those users with CC installed as gcc (including -stable), this
patch should have no effect. Variations of combinations have been
heavily tested on pointyhat-west. If there are any regressions, please
contact me.
Does this override setting CC explicitly in make.conf?
Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC
vs CC in the make system.
Dumb as I am, I also wonder when I see that in multimedia/x264:
...
USE_GCC=any
...
.if ${PORT_OPTIONS:MGCC44}
USE_GCC?= 4.4+
.endif
...
which seems to deny the intent of the GCC44 option
Sorry but I can not make the test at this present time
Matt
Claude Buisson
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/12/12 00:54, Claude Buisson wrote:
On 10/12/2012 05:00, matt wrote:
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of
USE_GCC=any to a port's Makefile, and then committed that change to
various ports. In most (but not all!) cases this will tell the port
build with gcc instead of clang (*) .
Why not USE_GCC ?= any for the poor guys like me who build (some)
ports with
USE_GCC=4.6 ?
For those users with CC installed as gcc (including -stable), this
patch should have no effect. Variations of combinations have been
heavily tested on pointyhat-west. If there are any regressions,
please
contact me.
Does this override setting CC explicitly in make.conf?
Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC
vs CC in the make system.
Dumb as I am, I also wonder when I see that in multimedia/x264:
...
USE_GCC=any
...
.if ${PORT_OPTIONS:MGCC44}
USE_GCC?=4.4+
.endif
...
which seems to deny the intent of the GCC44 option
Sorry but I can not make the test at this present time
Matt
Claude Buisson
I tested, and can confirm two things. CC is overpowered by USE_GCC=any,
which means that I end up with no sse4a and limited support for my arch
(Opteron 4xxx) because I can't set a better -march/cputype than
opteron-sse3. As far as I know base gcc doesn't even support sse4a. This
is really perhaps an issue with me setting CC in make.conf moreso than
ports, however this was the approved method of using clang by default as
well as the approved method of using ports gcc in the ports system. Is
there a new approved method?
M. Buisson's test case also fails, with base gcc being used even though
the gcc44 option is chosen. This may not break as many ports as it
might, but it will certainly create low performing editions of many
multimedia ports given the CPU features supported by either later clang
or gcc. Some will probably break?
If I missed something, please let me know, or if my testing is somehow
compromised. I removed make.conf (as mine is customized) for Claude's
test case, but it's possible something else may have affected my test
results. USE_GCC=any was manually added to the ports makefiles (test
case was editors/nano and multimedia/x264).
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of USE_GCC=any to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port build with gcc instead of clang (*) . Why not USE_GCC ?= any for the poor guys like me who build (some) ports with USE_GCC=4.6 ? For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. Does this override setting CC explicitly in make.conf? Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC vs CC in the make system. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/10/2012 02:45, Mark Linimon wrote: The commit mail hasn't gone through yet, so I guess I need to post this first and reference the commit mail later. Sometime in the near future, the default CC on -current will be switched to clang. The patch I have committed is a workaround -- an interim measure -- to get ready for this transition. I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of USE_GCC=any to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port build with gcc instead of clang (*) . Why not USE_GCC ?= any for the poor guys like me who build (some) ports with USE_GCC=4.6 ? For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. .. mcl Thanks, Claude Buisson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
Can we arrange exp builds with FORCE_BASE_CC_FOR_TESTING=clang that will report all ports with USE_GCC=* but build with clang? Lets say every three months or so? On Tue, Oct 09, 2012 at 07:45:23PM -0500, Mark Linimon wrote: The commit mail hasn't gone through yet, so I guess I need to post this first and reference the commit mail later. Sometime in the near future, the default CC on -current will be switched to clang. The patch I have committed is a workaround -- an interim measure -- to get ready for this transition. I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of USE_GCC=any to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port build with gcc instead of clang (*) . For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. You can see the difference in the errorlogs here: With USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121007231359.pointyhat-west/index-category.html Without USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121005165436.pointyhat-west/index-category.html While the absolute number of errors is not that much different, that is a false indication: over 2500 more packages are built with than without. For those who wish to build *only* with clang, and thus defeat the workaround, simply set FORCE_BASE_CC_FOR_TESTING=anything, either in the Makefile line, or, if you are adventurous, in your /etc/make.conf. We appreciate all the testing that we can get (it is too much for any small group of people, much less one person.) In the long run, I would like to see as many ports built natively with clang as possible, and I appreciate the work that people have been doing to move us towards that goal. However, once the switch is made, it would have been a burden to everyone tracking -current to have suddenly found themselves enlisted in that effort :-) So, for the medium-term, this workaround should reduce the POLA violation. *Note* that due to the high number (over a thousand!) ports that do not build with clang, I arbitrarily decided to apply the workaround only to ports that block 2 or more other ports from building union important ports. This does not mean that the workaround shouldn't be applied to other ports that are too hard to fix. This is part 1 of a set of patches that are being proposed to deal with the switchover. As I merge and test them some more, I will put them out for further review. Thanks. mcl * several ports are very, very, clever, and detect clang anyways; others build with gcc if CC is unset, but don't with CC=gcc. These ports are broken, and need to be fixed as we continue the process of switching over. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On Wed, Oct 10, 2012 at 05:11:07PM +0200, Roman Divacky wrote: Can we arrange exp builds with FORCE_BASE_CC_FOR_TESTING=clang that will report all ports with USE_GCC=* but build with clang? Sure. That was kind of the intention. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[HEADSUP] FYI: patch to ports that do not build with clang has been committed
The commit mail hasn't gone through yet, so I guess I need to post this first and reference the commit mail later. Sometime in the near future, the default CC on -current will be switched to clang. The patch I have committed is a workaround -- an interim measure -- to get ready for this transition. I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of USE_GCC=any to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port build with gcc instead of clang (*) . For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. You can see the difference in the errorlogs here: With USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121007231359.pointyhat-west/index-category.html Without USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121005165436.pointyhat-west/index-category.html While the absolute number of errors is not that much different, that is a false indication: over 2500 more packages are built with than without. For those who wish to build *only* with clang, and thus defeat the workaround, simply set FORCE_BASE_CC_FOR_TESTING=anything, either in the Makefile line, or, if you are adventurous, in your /etc/make.conf. We appreciate all the testing that we can get (it is too much for any small group of people, much less one person.) In the long run, I would like to see as many ports built natively with clang as possible, and I appreciate the work that people have been doing to move us towards that goal. However, once the switch is made, it would have been a burden to everyone tracking -current to have suddenly found themselves enlisted in that effort :-) So, for the medium-term, this workaround should reduce the POLA violation. *Note* that due to the high number (over a thousand!) ports that do not build with clang, I arbitrarily decided to apply the workaround only to ports that block 2 or more other ports from building union important ports. This does not mean that the workaround shouldn't be applied to other ports that are too hard to fix. This is part 1 of a set of patches that are being proposed to deal with the switchover. As I merge and test them some more, I will put them out for further review. Thanks. mcl * several ports are very, very, clever, and detect clang anyways; others build with gcc if CC is unset, but don't with CC=gcc. These ports are broken, and need to be fixed as we continue the process of switching over. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
