[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On 04-04-2009 18:49:50 -0600, Ryan Hill wrote:
+ # killing these two on OSX/Intel will disable SSE, resulting in failing
+ # compilations, as the headers expect SSE to be enabled (Apple knows
what
+ # hardware they run on afterall, don't they?)
+ [[ ${CHOST} == i?86-apple-darwin* ]] \
+ALLOWED_FLAGS=${ALLOWED_FLAGS} -march=prescott
-march=nocona
Why do these have to be specifically included? Aren't they handed by
34 export ALLOWED_FLAGS=${ALLOWED_FLAGS} -O -O0 -O1 -O2 -mcpu
-march -mtune
Looking at the current code, it can't even work properly. Even in the
case when ALLOWED_FLAGS is already set.
if [[ -z ${ALLOWED_FLAGS} ]] ; then
export ALLOWED_FLAGS=-pipe
export ALLOWED_FLAGS=${ALLOWED_FLAGS} -O -O0 -O1 -O2
-mcpu -march
Weird enough, it /did/ enable compilations to succeed in the past, but
it just can't in the current eclass, so it's bogus, and I will remove it
again.
Thanks for the check, much appreciated!
--
Fabian Groffen
Gentoo on a different level
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Sat, 04 Apr 2009 17:57:54 +
Fabian Groffen (grobian) grob...@gentoo.org wrote:
grobian 09/04/04 17:57:54
Modified: flag-o-matic.eclass
Log:
backport fix for x86-macos in filter-flags from Prefix
Revision ChangesPath
1.133eclass/flag-o-matic.eclass
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.133view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.133content-type=text/plain
diff :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.132r2=1.133
Index: flag-o-matic.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- flag-o-matic.eclass 21 Jan 2009 00:42:20 - 1.132
+++ flag-o-matic.eclass 4 Apr 2009 17:57:54 - 1.133
@@ -1,6 +1,6 @@
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v 1.132
2009/01/21 00:42:20 gengor Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v 1.133
2009/04/04 17:57:54 grobian Exp $
# @ECLASS: flag-o-matic.eclass
# @MAINTAINER:
@@ -52,6 +52,12 @@
-m32 -m64 -mabi -mlittle-endian -mbig-endian -EL -EB -fPIC \
-mlive-g0 -mcmodel -mstack-bias -mno-stack-bias \
-msecure-plt -m*-toc -D* -U*
+
+ # killing these two on OSX/Intel will disable SSE, resulting in failing
+ # compilations, as the headers expect SSE to be enabled (Apple knows
what
+ # hardware they run on afterall, don't they?)
+ [[ ${CHOST} == i?86-apple-darwin* ]] \
+ ALLOWED_FLAGS=${ALLOWED_FLAGS} -march=prescott
-march=nocona
Why do these have to be specifically included? Aren't they handed by
34 export ALLOWED_FLAGS=${ALLOWED_FLAGS} -O -O0 -O1 -O2 -mcpu -march
-mtune
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Mon, 18 Feb 2008 18:15:18 -0500 Doug Klima [EMAIL PROTECTED] wrote: How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? 6 You think there are 6 people running stable Portage? Either you think all the users (including those installing off old stages) are running ~arch, or you think Gentoo has died, or you think everyone's moved to Paludis... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Ciaran McCreesh wrote: On Mon, 18 Feb 2008 18:15:18 -0500 Doug Klima [EMAIL PROTECTED] wrote: How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? 6 You think there are 6 people running stable Portage? Either you think all the users (including those installing off old stages) are running ~arch, or you think Gentoo has died, or you think everyone's moved to Paludis... Stupid questions deserve stupid answers. So I arbitrarily picked a number and gave it to you. A better statement on your part would have been We need to ensure compatibility for the greatest amount of users and requiring users to have a version of Portage released after January 4th when it's only the middle of February is not going to ensure the greatest compatibility. The previous policy was always 6 months between breaks like this. You're free to reword the above to however you see fit. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Tue, 19 Feb 2008 08:44:43 -0500 Doug Klima [EMAIL PROTECTED] wrote: A better statement on your part would have been We need to ensure compatibility for the greatest amount of users and requiring users to have a version of Portage released after January 4th when it's only the middle of February is not going to ensure the greatest compatibility. The previous policy was always 6 months between breaks like this. You're free to reword the above to however you see fit. You mean the change should of course have been an EAPI bump. hth, -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Ciaran McCreesh wrote: On Tue, 19 Feb 2008 08:44:43 -0500 Doug Klima [EMAIL PROTECTED] wrote: A better statement on your part would have been We need to ensure compatibility for the greatest amount of users and requiring users to have a version of Portage released after January 4th when it's only the middle of February is not going to ensure the greatest compatibility. The previous policy was always 6 months between breaks like this. You're free to reword the above to however you see fit. You mean the change should of course have been an EAPI bump. hth, As it's been explained to me by one of your fellow PMS developers, since EAPI=0 is not complete yet, there will be no work on further EAPIs until EAPI=0 is complete. Since this is the case and we still need to make changes, we must revert back to the previous policy with regard to changes. I personally would love to see EAPI=0 published as a draft for users and developers to see. I feel that it's going to be one of those things that's going to be difficult to nail down do the the nature of a whole package manager being developed without any specifications . Writing a concrete set of specifications after the fact, which encompass every little nook and cranny, is a difficult and tedious process that requires testing every single code path. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Doug Klima [EMAIL PROTECTED] said: As it's been explained to me by one of your fellow PMS developers, since EAPI=0 is not complete yet, there will be no work on further EAPIs until EAPI=0 is complete. Since this is the case and we still need to make changes, we must revert back to the previous policy with regard to changes. Just to clarify slightly: I won't be working on anything other than EAPI=0. Other people may be, but the council said in the latest meeting that they feel we should get EAPI=0 done before adding any new EAPIs to the tree. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgp3y2lGk2cbz.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Tue, 19 Feb 2008 09:42:43 -0500 Doug Klima [EMAIL PROTECTED] wrote: As it's been explained to me by one of your fellow PMS developers, since EAPI=0 is not complete yet, there will be no work on further EAPIs until EAPI=0 is complete. No-one who has worked upon PMS has said that. I personally would love to see EAPI=0 published as a draft for users and developers to see. PMS drafts have been available for ages. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On 18:20 Mon 18 Feb , Sven Wegener (swegener) wrote:
swegener08/02/18 18:20:47
Modified: flag-o-matic.eclass
Log:
redirect the ewarn message to stderr
Revision ChangesPath
1.122eclass/flag-o-matic.eclass
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.122view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.122content-type=text/plain
diff :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.121r2=1.122
@@ -614,7 +614,7 @@
# @DESCRIPTION:
# DEPRECATED - Gets the flags needed for NOW binding
bindnow-flags() {
- ewarn QA: stop using the bindnow-flags function ... simply drop it
from your ebuild
+ ewarn QA: stop using the bindnow-flags function ... simply drop it
from your ebuild 2
This seems like something ewarn should do on its own.
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Mon, 18 Feb 2008 13:20:52 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: This seems like something ewarn should do on its own. http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.121view=markup http://thread.gmane.org/gmane.linux.gentoo.user/194929 hth, -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Monday 18 February 2008 21:20:52 Donnie Berkholz wrote:
@@ -614,7 +614,7 @@
# @DESCRIPTION:
# DEPRECATED - Gets the flags needed for NOW binding
bindnow-flags() {
- ewarn QA: stop using the bindnow-flags function ... simply drop it
from your ebuild + ewarn QA: stop using the bindnow-flags function ...
simply drop it from your ebuild 2
This seems like something ewarn should do on its own.
baselayout and portage have always echoed ewarn to stdout and not stderr.
Warnings are NOT errors, so why use stderr? If it's an error, use eerror which
DOES goto stderr.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On 21:37 Mon 18 Feb , Ciaran McCreesh wrote: On Mon, 18 Feb 2008 13:20:52 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: This seems like something ewarn should do on its own. http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.121view=markup I'm not sure what I'm supposed to get out of this, besides seeing that a lot of stuff is sent to stderr. http://thread.gmane.org/gmane.linux.gentoo.user/194929 Right, I figured the reason was something along the lines of info going to stdout when only flags should. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Mon, 18 Feb 2008 13:54:34 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? How many people are running a Portage version released after January 4? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Mon, 18 Feb 2008 16:26:11 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Mon, 18 Feb 2008 13:54:34 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? I'd mutter something about EAPIs here, but really if people are having difficulty understanding the necessity of the original commit, I suspect it's a lost cause... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Ciaran McCreesh wrote: On Mon, 18 Feb 2008 16:26:11 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Mon, 18 Feb 2008 13:54:34 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? I'd mutter something about EAPIs here, but really if people are having difficulty understanding the necessity of the original commit, I suspect it's a lost cause... 6 -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
