On 10/4/12 4:16 PM, Phil Blundell wrote:
On Thu, 2012-10-04 at 16:00 -0500, Mark Hatle wrote:
This is only one runtime. You have multiple compilers all capable of producing
software compatible with the same ABI. The default (oe) compiler is used,
unless otherwise configured. The alternative(s) are used for optimization of
various items. I mentioned ICC, because it's one that I know today people are
using and it is capable of replacing gcc in many applications.
If that's the case then it doesn't seem like it ought to be necessary to
override most of the variables you mentioned. Tools like ar, ranlib and
strip are generic to a binary format and should work fine with the
output from any compiler. Also, if you're linking with GNU libc then
the chances are that you need to use one of the GNU linkers (be that
ld.bfd or gold) since I suspect most third party link editors will not
work very well. And, if you have assembly source on hand, it's probably
going to be written in GAS dialect so selecting an alternative assembler
as ${AS} is unlikely to gain much.
I realize not everything will be overridden, and I even expect in many cases
only the CC and CXX will be defined.
I'm aware of at least one third party compiler that uses a different dialect
then GAS. And in that case the compiler and assembly would be overwritten..
(mind you anything that uses gas syntax would of course be incompatible and blow
up, which begs the question -- do you really want to use AS then?)
But I figure if we cover all of the cases then we should be good no matter what.
So, it kind of seems like the only variables you're likely to need to
change are CC, CXX and the corresponding FLAGS. I guess you might also
want to override F77 in theory though I'm not sure there are many people
using Fortran in an embedded environment.
I'm aware of one company that -was- using Fortran, I don't know if they still
are. (And they were not using the GNU F77....)
Your proposed "toolchain-icc" override sounds like a reasonable enough
way to accomplish that, anyway. The only problem it doesn't seem to
solve is the use-case of "everything that supports icc, I want to build
with icc; everything that doesn't support icc, I want to build with
gcc". But I'm not sure this really matters much.
There needs to be a way to set the TOOLCHAIN 'type' on a blacklist or whitelist
basis. I.e. in a whitelist, you simply set it to 'gnu' (or whatever), which is
more or less what I'd expect the default behavior to be. Then for every recipe
you are aware of that works -- you'd overriver the TOOLCHAIN-pn_package w/ 'alt'.
Alternatively you could do it as a blacklist.. set TOOLCHAIN = 'alt' and then
blacklist items by setting the items to 'gnu' (or whatever).
Both have advantages.. personally I'd suggest the former rather then later
approach, it's easier to support and then you can focus porting efforts on the
packages that you believe you need the most optimizations in.
--Mark
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
