Re: [gentoo-dev] Lastrites: net-im/linpopup, app-office/teapot, net-irc/bitchx, sys-power/cpufrequtils, x11-plugins/gkrellm-cpufreq, media-sound/gnome-alsamixer, sys-devel/ac-archive, net-misc/emirror, net-wireless/wimax, net-wireless/wimax-tools,rox-extra/clock, app-arch/rpm5, app-admin/gksu-polkit, sys-apps/uhinv, net-libs/pjsip, net-voip/sflphone, net-im/ekg, sys-firmware/iwl2030-ucode, sys-firmware/iwl5000-ucode, sys-firmware/iwl2000-ucode,sys-firmware/iwl5150-ucode, dev-perl/MooseX-AttributeHelpers,media-gfx/truevision,media-gfx/f-spot,net-wireless/cinnamon-bluetooth,app-misc/cdcollect, net-wireless/ussp-push

[Diamond]

On Tue, 09 Dec 2014 11:05:31 +0100
Pacho Ramos <pacho@g.o> wrote:

>
> Regarding the gkrellm-plugins, looks like Fedora is supplying this
> one:
> http://pkgs.fedoraproject.org/cgit/gkrellm-freq.git/tree/gkrellm-freq.spec
>
>
 
I rewrote ebuild for gkrellm-gkfreq plugin a bit
 
 https://github.com/cerebrum/dr/blob/master/x11-plugins/gkrellm-gkfreq/gkrellm-gkfreq-2.3.ebuild

And sent this patch upstream

https://github.com/cerebrum/dr/blob/master/x11-plugins/gkrellm-gkfreq/files/gkrellm-gkfreq-2.3-make.patch
https://sourceforge.net/p/gkrellm-gkfreq/feature-requests/2/

Why do we have a function tc-getCC for CC environment variable and why
we don't use CC environment variable automatically? With this patch
CFLAGS and LDFLAGS are substituted automatically without garbage in
ebuild. Why don't we use the same strategy for CC variable?

"Sometimes a package will try to use a bizarre compiler, or will need
to be told which compiler to use. In these situations, the tc-getCC()
function from toolchain-funcs.eclass should be used...
Note: It is not correct to use the ${CC} variable for this purpose."
https://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html

And why CC variable gives me "cc" but not "x86_64-pc-linux-gnu-gcc" as
it should be? Am I right that it's a bit strange?