Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ebuild not using CFLAGS (e.g. mythtv-0.18-r2, mythtv-0.18.1)
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Reverend
n00b
n00b


Joined: 19 Mar 2003
Posts: 22

PostPosted: Wed May 25, 2005 9:49 pm    Post subject: ebuild not using CFLAGS (e.g. mythtv-0.18-r2, mythtv-0.18.1) Reply with quote

When emerging mythtv, I get this note:
Quote:
*
* Please note, this ebuild does not use your CFLAGS and CXXFLAGS. It determines
* a sane set and uses those. Please do not attempt to override this behavior.
*

Why is this? It seems antithetical to the Portage Way. I can understand if there are some ewarning suggestions on how to modify your make.conf to get the most out of MythTV, but completely ignoring my settings seems bad.

To give an example of where this type of behavior breaks things, there's emerge --buildpkg. 'man emerge' states:
Quote:
--buildpkg (-b)
Tells emerge to build binary packages for all ebuilds processed
in addition to actually merging the packages. Useful for main-
tainers or if you administrate multiple Gentoo Linux systems
(build once, emerge tbz2s everywhere). The package will be cre-
ated in the ${PKGDIR}/All directory. An alternative for
already-merged packages is to use quickpkg which creates a tbz2
from the live filesystem.


Here's a scenario where this type of ebuild fails the intended purpose of Portage and this quote (as I understand it): I do all of my compiling on a P4 (my fastest machine) and deploy (with emerge --usepkg) on a set of P4s and P3s. I use a conservative -march=pentium3 in my CFLAGS so that all of my binaries will run on both the P3s and P4s. However, with this particular ebuild, my make.conf file is ignored and mythtv is built with -march=pentium4, making my .tbz binary not work on my other systems.

Anyway, I wanted to start a conversation about whether this behavior is good or not. It seems weird that a particular ebuild is overriding the intended behavior of Portage.
Back to top
View user's profile Send private message
Pythonhead
Developer
Developer


Joined: 16 Dec 2002
Posts: 1801
Location: Redondo Beach, Republic of Calif.

PostPosted: Wed May 25, 2005 11:02 pm    Post subject: Re: ebuild not using CFLAGS (e.g. mythtv-0.18-r2, mythtv-0.1 Reply with quote

Reverend wrote:
When emerging mythtv, I get this note:
Quote:
*
* Please note, this ebuild does not use your CFLAGS and CXXFLAGS. It determines
* a sane set and uses those. Please do not attempt to override this behavior.
*

Why is this?


Very few developers read the forums, so you'd be best off reading the Changelog and mailing the author.

Quote:

Here's a scenario where this type of ebuild fails the intended purpose of Portage and this quote (as I understand it): I do all of my compiling on a P4 (my fastest machine) and deploy (with emerge --usepkg) on a set of P4s and P3s. I use a conservative -march=pentium3 in my CFLAGS so that all of my binaries will run on both the P3s and P4s. However, with this particular ebuild, my make.conf file is ignored and mythtv is built with -march=pentium4, making my .tbz binary not work on my other systems.


File a bug report, preferably with a patch that will put -march back in CFLAGS, but you might check with the ebuild maintainer first. Reading the comments in the ebuild makes me think this is being done due to Myth's author requesting it (the upstream comment). If a package's author doesn't support anything but his own recommended CFLAGS, theres not much we can do unless someone wants to start supplying the fixes.
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Thu May 26, 2005 3:59 am    Post subject: Reply with quote

the intended behaviour of portage is to compile, install, and manage software packages. many ebuilds override CFLAGS, usually because the package in question is broken by certain options. your situation is different than most, and different from the situation that the ebuild is trying to prevent, so obviously it's not foolproof and there are always exceptions.

whether this is a good thing or not. i think it is, if only for the safety-net factor. many people argue this is not the Gentoo Way. Gentoo is about Choice! this is true. but people have to be aware that decisions have consequences and sometimes those consequences suck. ebuilds like this don't take away your power to choose. you certainly still have the choice to edit the ebuild to remove the flag stripping. making it an extra effort may be an annoyance but it's there because of the collective experience of the community. it's not done to repress your freedom, but probably because long ago many people broke their systems and then complained about it very loudly for a very long time. :wink:
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
Reverend
n00b
n00b


Joined: 19 Mar 2003
Posts: 22

PostPosted: Thu May 26, 2005 5:01 am    Post subject: Reply with quote

dirtyepic wrote:
many ebuilds override CFLAGS, usually because the package in question is broken by certain options.


I'm sure this is true, but would it not be better if the ebuild detected the offending options and issued an error (or a warning)? That way, the user would be aware of what was happening and could change his/her options themselves. Automatically overriding the CFLAGS breaks other behavior in portage, such as the --buildpkg --usepkg issue I described above.

I'm sure there are other issues that I am not aware of... I'm just trying to understand this issue when it seems that there might be better ways of handling it without breaking certain portage behavior. But, like I said, I could be wrong or overlooking something.
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Thu May 26, 2005 6:06 am    Post subject: Reply with quote

how many ppl would miss those warnings vs. how many people specifically need to know when a flag gets stripped/altered?
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
ciaranm
Retired Dev
Retired Dev


Joined: 19 Jul 2003
Posts: 1719
Location: In Hiding

PostPosted: Thu May 26, 2005 10:23 am    Post subject: Reply with quote

meh. I consider outright ignoring of CFLAGS to be a bug.
Back to top
View user's profile Send private message
Cardoe
Developer
Developer


Joined: 28 Jun 2002
Posts: 32

PostPosted: Fri May 27, 2005 6:46 am    Post subject: Reply with quote

Unfortunately, do too piss poor ASM and the upstream probably not understanding the ASM they play with. Nearly every CFLAG makes the package not compile. Upstream refuses to work with any Gentoo user on any issue until this latest revision. This latest revision has cut the reports of "OMG IT DOESN"T WORK!!!!!11111oneoneoneone" to my e-mail box, to the IRC channel, especially upstream.. which is where a lot of Gentoo users liked to go with their crazy CFLAGS. That essentially I was having to filter way too much. What would have probably been a better compromise is strip-flags from flag-o-matic. But I didn't know how to add in -fomit-frame-pointer, which is needed because of the register count in the ASM. So.... I can do that and strip out all the flags and just add it back. Or just use get-flag and get march and mtune since their detect script will accept those.
_________________
Cardoe

Gentoo Developer
Gentopia, MythTV, D-Bus
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum